perm filename COMMON.5[COM,LSP] blob
sn#807410 filedate 1985-09-14 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00719 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00097 00002
C00098 00003 ∂24-Jan-85 1800 Moon@SCRC-STONY-BROOK.ARPA Make-Hash-Table
C00103 00004 ∂24-Jan-85 1800 Moon@SCRC-STONY-BROOK.ARPA Make-Hash-Table
C00108 00005 ∂25-Jan-85 0801 REM@IMSSS how to document yellow page entries, belated discussion by REM
C00111 00006 ∂26-Jan-85 1753 FAHLMAN@CMU-CS-C.ARPA how to document yellow page entries, belated discussion by REM
C00114 00007 ∂26-Jan-85 2003 FAHLMAN@CMU-CS-C.ARPA A proposal
C00123 00008 ∂26-Jan-85 2139 Moon@SCRC-STONY-BROOK.ARPA A proposal
C00126 00009 ∂26-Jan-85 2216 REM%IMSSS.#Pup@SU-SCORE.ARPA Character macros, erratum
C00128 00010 ∂26-Jan-85 2340 fateman%ucbdali@Berkeley Re: A proposal
C00135 00011 ∂27-Jan-85 0952 FAHLMAN@CMU-CS-C.ARPA A proposal
C00142 00012 ∂27-Jan-85 1701 @MIT-MC:PGS@MIT-OZ definition of lexical closure
C00147 00013 ∂27-Jan-85 1705 fateman%ucbdali@Berkeley Re: A proposal
C00150 00014 ∂27-Jan-85 1727 FAHLMAN@CMU-CS-C.ARPA A proposal
C00154 00015 ∂28-Jan-85 0511 OHLANDER@USC-ISI.ARPA Re: A proposal
C00158 00016 ∂28-Jan-85 0739 OHLANDER@USC-ISI.ARPA Re: A proposal
C00161 00017 ∂29-Jan-85 0335 @MIT-MC:PGS@MIT-OZ definition of lexical closure
C00164 00018 ∂29-Jan-85 1328 GRISS%hp-hulk.csnet@csnet-relay.arpa Re: how to document yellow page entries, belated discussion by REM
C00166 00019 ∂03-Feb-85 0833 RAM@CMU-CS-C.ARPA Defstruct copiers and included structures
C00168 00020 ∂04-Feb-85 1248 Moon@SCRC-STONY-BROOK.ARPA FLET and the INLINE declaration
C00170 00021 ∂06-Feb-85 0950 brown@DEC-HUDSON Clearly non-controversial
C00174 00022 ∂06-Feb-85 1847 RAM@CMU-CS-C.ARPA of course you don't copy everything that includes that structure!!
C00178 00023 ∂07-Feb-85 2224 WHOLEY@CMU-CS-C.ARPA Clearly non-controversial
C00184 00024 ∂07-Feb-85 2330 WHOLEY@CMU-CS-C.ARPA Clearly non-controversial
C00190 00025 ∂12-Feb-85 1931 JLW Your non-controversial suggestions for function names
C00192 00026 ∂14-Feb-85 1140 KMP@SCRC-STONY-BROOK.ARPA Not clearly non-controversial
C00198 00027 ∂18-Feb-85 1028 HEDRICK@RUTGERS.ARPA doc strings
C00199 00028 ∂20-Feb-85 0216 rwg@RUSSIAN.SPA.Symbolics.COM gcd of rationals--flame added in proof
C00208 00029 ∂21-Feb-85 1334 godot!gls@AQUINAS gcd of rationals--flame added in proof
C00210 00030 ∂26-Feb-85 0909 hpfclp!paul%hplabs.csnet@csnet-relay.arpa truncate/round/floor/ceiling functions
C00213 00031 ∂26-Feb-85 1648 RAM@CMU-CS-C.ARPA truncate/round/floor/ceiling functions
C00215 00032 ∂04-Mar-85 0934 RAM@CMU-CS-C.ARPA do-xxx-symbols
C00220 00033 ∂04-Mar-85 1048 FAHLMAN@CMU-CS-C.ARPA do-xxx-symbols
C00224 00034 ∂04-Mar-85 1606 HEDRICK@RUTGERS.ARPA Re: do-xxx-symbols
C00226 00035 ∂04-Mar-85 1851 HEDRICK@RUTGERS.ARPA Re: do-xxx-symbols
C00230 00036 ∂04-Mar-85 2026 FAHLMAN@CMU-CS-C.ARPA do-xxx-symbols
C00233 00037 ∂04-Mar-85 2036 HEDRICK@RUTGERS.ARPA Re: do-xxx-symbols
C00236 00038 ∂05-Mar-85 1541 godot!gls@AQUINAS Complex arc tangent
C00238 00039 ∂07-Mar-85 1707 dzg@cmu-cs-spice.arpa file-length
C00243 00040 ∂07-Mar-85 1707 dzg@cmu-cs-spice.arpa file-length
C00248 00041 ∂07-Mar-85 1708 dzg@cmu-cs-spice.arpa file-length
C00253 00042 ∂07-Mar-85 2026 FAHLMAN@CMU-CS-C.ARPA file-length
C00255 00043 ∂07-Mar-85 2112 KMP@SCRC-STONY-BROOK.ARPA FILE-LENGTH
C00259 00044 ∂07-Mar-85 2130 KMP@SCRC-STONY-BROOK.ARPA DO-SYMBOLS finding shadowed symbols
C00264 00045 ∂08-Mar-85 0827 FAHLMAN@CMU-CS-C.ARPA DO-SYMBOLS finding shadowed symbols
C00268 00046 ∂08-Mar-85 1140 HEDRICK@RUTGERS.ARPA Re: file-length
C00271 00047 ∂08-Mar-85 1442 RAM@CMU-CS-C.ARPA file-length
C00273 00048 ∂12-Mar-85 0710 hpfclp!paul%hplabs.csnet@csnet-relay.arpa float-digits
C00275 00049 ∂12-Mar-85 0748 FAHLMAN@CMU-CS-C.ARPA float-digits
C00278 00050 ∂19-Mar-85 0056 JLW DO-SYMBOLS: duplicates and shadowings
C00281 00051 ∂19-Mar-85 0114 JLW File-length on pathnames
C00283 00052 ∂19-Mar-85 0717 FAHLMAN@CMU-CS-C.ARPA DO-SYMBOLS: duplicates and shadowings
C00285 00053 ∂19-Mar-85 1344 RAM@CMU-CS-C.ARPA File-length on pathnames
C00289 00054 ∂19-Mar-85 1855 FAHLMAN@CMU-CS-C.ARPA [Gall: Bug Report]
C00317 00055 ∂19-Mar-85 2212 cork%umass-cs.csnet@csnet-relay.arpa Implementation of MAP, SOME, EVERY, etc...
C00319 00056 ∂19-Mar-85 2228 REM@IMSSS Default attributes of copy due to SUBSEQ
C00322 00057 ∂19-Mar-85 2228 REM@IMSSS What should CLOSE return? Closed-channel-object, or truefilename.
C00325 00058 ∂19-Mar-85 2228 REM@IMSSS Length of currently-open-for-write file is ambiguous or meaningless
C00331 00059 ∂20-Mar-85 0132 RAM@CMU-CS-C.ARPA Length of currently-open-for-write file is ambiguous or meaningless
C00333 00060 ∂20-Mar-85 0141 RAM@CMU-CS-C.ARPA Default attributes of copy due to SUBSEQ
C00335 00061 ∂20-Mar-85 0144 RAM@CMU-CS-C.ARPA Default attributes of copy due to SUBSEQ
C00337 00062 ∂20-Mar-85 0208 RAM@CMU-CS-C.ARPA Implementation of MAP, SOME, EVERY, etc...
C00340 00063 ∂20-Mar-85 2032 DDYER@USC-ISIB.ARPA Re: Implementation of MAP, SOME, EVERY, etc...
C00342 00064 ∂20-Mar-85 2053 RAM@CMU-CS-C.ARPA Query (FILE-LENGTH in particular) of file by name when open
C00344 00065 ∂20-Mar-85 2052 RAM@CMU-CS-C.ARPA [REM: Query (FILE-LENGTH in particular) of file by name when open]
C00348 00066 ∂20-Mar-85 2052 RAM@CMU-CS-C.ARPA [REM: destructive operations on circular emulation of infinite list]
C00355 00067 ∂20-Mar-85 2122 JLW Implementation of MAP, SOME, etc
C00356 00068 ∂20-Mar-85 2152 Gall.HIS←Guest@MIT-MULTICS.ARPA Follow-up and New Questions
C00368 00069 ∂21-Mar-85 0056 RAM@CMU-CS-C.ARPA Implementation of MAP, SOME, EVERY, etc...
C00370 00070 ∂21-Mar-85 0111 RAM@CMU-CS-C.ARPA Follow-up and New Questions
C00372 00071 ∂21-Mar-85 1302 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: Follow-up and New Questions
C00375 00072 ∂21-Mar-85 1317 FAHLMAN@CMU-CS-C.ARPA Follow-up and New Questions
C00377 00073 ∂21-Mar-85 1352 Gall.HIS←Guest@MIT-MULTICS.ARPA Lost bet
C00379 00074 ∂21-Mar-85 2218 cork%umass-cs.csnet@csnet-relay.arpa More on MAP, SOME, EVERY, etc.....
C00385 00075 ∂25-Mar-85 1831 JLW DELFILE, thanks to DWIM
C00387 00076 ∂25-Mar-85 1914 JLW Excluding some symbols from DO-ALL-SYMBOLS
C00389 00077 ∂26-Mar-85 0312 JLW Previous note about DELFILE/DWIM
C00390 00078 ∂27-Mar-85 1240 eak@angband multiple-value-setq
C00391 00079 ∂27-Mar-85 1241 eak@angband values-list
C00392 00080 ∂27-Mar-85 1807 Moon@SCRC-STONY-BROOK.ARPA do-xxx-symbols
C00397 00081 ∂27-Mar-85 1808 Moon@SCRC-STONY-BROOK.ARPA Implementation of MAP, SOME, EVERY, etc...
C00400 00082 ∂27-Mar-85 1818 FAHLMAN@CMU-CS-C.ARPA multiple-value-setq
C00402 00083 ∂27-Mar-85 1820 FAHLMAN@CMU-CS-C.ARPA do-xxx-symbols
C00405 00084 ∂27-Mar-85 1820 FAHLMAN@CMU-CS-C.ARPA values-list
C00408 00085 ∂27-Mar-85 2020 FAHLMAN@CMU-CS-C.ARPA Implementation of MAP, SOME, EVERY, etc...
C00410 00086 ∂28-Mar-85 0553 Moon@SCRC-STONY-BROOK.ARPA [Gall: Bug Report]
C00431 00087 ∂28-Mar-85 1036 Moon@SCRC-STONY-BROOK.ARPA Implementation of MAP, SOME, EVERY, etc...
C00434 00088 ∂28-Mar-85 1116 FAHLMAN@CMU-CS-C.ARPA values-list
C00436 00089 ∂28-Mar-85 1126 Moon@SCRC-STONY-BROOK.ARPA values-list
C00439 00090 ∂28-Mar-85 1154 EAK@MIT-MC values-list
C00441 00091 ∂28-Mar-85 1158 RWK@SCRC-STONY-BROOK.ARPA Clearly non-controversial
C00444 00092 ∂28-Mar-85 1433 DLW@SCRC-STONY-BROOK.ARPA [Gall: Bug Report]
C00447 00093 ∂28-Mar-85 1434 Moon@SCRC-STONY-BROOK.ARPA values-list
C00449 00094 ∂28-Mar-85 1621 Moon@SCRC-STONY-BROOK.ARPA [Gall: Bug Report]
C00453 00095 ∂28-Mar-85 2216 cork%umass-cs.csnet@csnet-relay.arpa More on MAP, SOME, EVERY, etc.....
C00460 00096 ∂29-Mar-85 2041 TIM@MIT-MC multiple-value-setf
C00461 00097 ∂01-Apr-85 0118 masinter.pa@Xerox.ARPA Re: Arg count checking
C00465 00098 ∂01-Apr-85 1123 godot!gls@cca-unix [Gall: Bug Report]
C00467 00099 ∂01-Apr-85 1127 godot!gls@cca-unix Implementation of MAP, SOME, EVERY, etc...
C00471 00100 ∂01-Apr-85 1844 KMP@SCRC-QUABBIN.ARPA Re: Arg count checking
C00480 00101 ∂02-Apr-85 0745 DLW@SCRC-QUABBIN.ARPA Re: Arg count checking
C00484 00102 ∂02-Apr-85 1201 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: PROCLAIM [Gall: Bug Report]
C00487 00103 ∂02-Apr-85 1201 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: INTERN [Gall: Bug Report]
C00493 00104 ∂02-Apr-85 1218 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: NIL and DEFCONSTANT [Gall: Bug Report]
C00495 00105 ∂02-Apr-85 1218 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: SPECIAL FUNCTION NAME [Gall: Bug Report]
C00499 00106 ∂02-Apr-85 1218 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: [Gall: Bug Report]
C00504 00107 ∂02-Apr-85 1218 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: COPY-SYMBOL [Gall: Bug Report]
C00507 00108 ∂02-Apr-85 1327 JAR@MIT-MC SPECIAL FUNCTION NAME [Gall: Bug Report]
C00512 00109 ∂02-Apr-85 1329 fateman%ucbdali@Berkeley CLRM?
C00514 00110 ∂02-Apr-85 1722 Moon@SCRC-STONY-BROOK.ARPA Re: NIL and DEFCONSTANT [Gall: Bug Report]
C00517 00111 ∂02-Apr-85 1724 Moon@SCRC-STONY-BROOK.ARPA Re: INTERN [Gall: Bug Report]
C00526 00112 ∂02-Apr-85 2002 FAHLMAN@CMU-CS-C.ARPA INTERN [Gall: Bug Report]
C00531 00113 ∂02-Apr-85 2021 FAHLMAN@CMU-CS-C.ARPA NIL and DEFCONSTANT [Gall: Bug Report]
C00534 00114 ∂03-Apr-85 1226 JLW INTERN and "intern" -- the unwise choice of terminology
C00537 00115 ∂03-Apr-85 1438 Gall.HIS←Guest@MIT-MULTICS.ARPA
C00543 00116 ∂03-Apr-85 1502 JLW Assymetry between argument-passing and value-returning
C00547 00117 ∂03-Apr-85 1556 BSG@SCRC-STONY-BROOK.ARPA Re: Arg count checking
C00551 00118 ∂03-Apr-85 1749 Masinter.pa@Xerox.ARPA Re: SPECIAL FUNCTION NAME [Gall: Bug Report]
C00553 00119 ∂03-Apr-85 1843 Moon@SCRC-QUABBIN.ARPA INTERN and "intern" -- the unwise choice of terminology
C00557 00120 ∂03-Apr-85 1846 KSH@MIT-MC
C00560 00121 ∂03-Apr-85 2043 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: INTERN [Gall: Bug Report]
C00568 00122 ∂03-Apr-85 2105 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: NIL and DEFCONSTANT [Gall: Bug Report]
C00571 00123 ∂03-Apr-85 2110 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: What should CLOSE return?
C00577 00124 ∂04-Apr-85 0750 RAM@CMU-CS-C.ARPA INTERN and "intern" -- the unwise choice of terminology
C00580 00125 ∂04-Apr-85 1104 Moon@SCRC-STONY-BROOK.ARPA INTERN and "intern" -- the unwise choice of terminology
C00583 00126 ∂04-Apr-85 1345 JLW "home-ifying" symbols
C00586 00127 ∂04-Apr-85 1423 RAM@CMU-CS-C.ARPA "home-ifying" symbols
C00588 00128 ∂04-Apr-85 1812 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: INTERN and "intern" -- the unwise choice of terminology
C00591 00129 ∂04-Apr-85 2042 FAHLMAN@CMU-CS-C.ARPA Intern
C00593 00130 ∂04-Apr-85 2046 FAHLMAN@CMU-CS-C.ARPA Minor correction
C00594 00131 ∂04-Apr-85 2056 FAHLMAN@CMU-CS-C.ARPA NIL and DEFCONSTANT [Gall: Bug Report]
C00596 00132 ∂05-Apr-85 1106 Moon@SCRC-STONY-BROOK.ARPA Intern
C00599 00133 ∂05-Apr-85 1227 REM%IMSSS.#Pup@SU-SCORE.ARPA Any complete CL implementations??
C00602 00134 ∂05-Apr-85 1740 @SU-SCORE.ARPA:HEDRICK@RUTGERS.ARPA Re: Any complete CL implementations??
C00606 00135 ∂07-Apr-85 2026 FAHLMAN@CMU-CS-C.ARPA Any complete CL implementations??
C00609 00136 ∂08-Apr-85 0723 RAM@CMU-CS-C.ARPA Probe-File and proposed extension.
C00612 00137 ∂08-Apr-85 0821 gls%AQUINAS.TMC@Think NIL and DEFCONSTANT [Gall: Bug Report]
C00614 00138 ∂08-Apr-85 1134 Moon@SCRC-STONY-BROOK.ARPA Probe-File and proposed extension.
C00618 00139 ∂08-Apr-85 1156 RAM@CMU-CS-C.ARPA Probe-File and proposed extension.
C00621 00140 ∂08-Apr-85 1208 greek@DEC-HUDSON More on PROBE-FILE.
C00622 00141 ∂08-Apr-85 1208 greek@DEC-HUDSON PROBE-FILE
C00624 00142 ∂08-Apr-85 1222 RAM@CMU-CS-C.ARPA PROBE-FILE
C00626 00143 ∂08-Apr-85 1234 RAM@CMU-CS-C.ARPA PROBE-FILE
C00628 00144 ∂08-Apr-85 1345 REM@IMSSS error-protected OPEN isn't a good way to fake a probe
C00631 00145 ∂08-Apr-85 1446 Moon@SCRC-STONY-BROOK.ARPA Probe-File and proposed extension.
C00643 00146 ∂08-Apr-85 1452 Moon@SCRC-STONY-BROOK.ARPA error-protected OPEN isn't a good way to fake a probe
C00647 00147 ∂08-Apr-85 1531 RAM@CMU-CS-C.ARPA Probe-File and proposed extension.
C00650 00148 ∂08-Apr-85 1719 card.pa@Xerox.ARPA Re: Arg count checking
C00657 00149 ∂08-Apr-85 1736 KMP@SCRC-STONY-BROOK.ARPA PROBE-FILE
C00665 00150 ∂08-Apr-85 1937 FAHLMAN@CMU-CS-C.ARPA NIL and DEFCONSTANT [Gall: Bug Report]
C00668 00151 ∂08-Apr-85 1946 fateman%ucbdali@Berkeley Re: Arg count checking
C00670 00152 ∂09-Apr-85 0100 hplabs!perdue%hplabs.csnet@csnet-relay.arpa Compilation and package system
C00674 00153 ∂09-Apr-85 0448 REM@IMSSS I agree, but manual should tell LUSERs why
C00679 00154 ∂09-Apr-85 0451 REM@IMSSS READ loses info as to whether package is specified or not, my fix
C00682 00155 ∂09-Apr-85 0709 gls%AQUINAS.TMC@Think NIL and DEFCONSTANT [Gall: Bug Report]
C00686 00156 ∂09-Apr-85 1147 root%bostonu.csnet@csnet-relay.arpa Re: Arg count checking
C00689 00157 ∂09-Apr-85 1341 DLW@SCRC-STONY-BROOK.ARPA Re: Arg count checking
C00691 00158 ∂09-Apr-85 1352 DLW@SCRC-STONY-BROOK.ARPA Compilation and package system
C00693 00159 ∂09-Apr-85 1722 JLW Arg cont checking, optionals, keywords, etc
C00695 00160 ∂09-Apr-85 1803 Moon@SCRC-STONY-BROOK.ARPA Probe-File and proposed extension.
C00701 00161 ∂09-Apr-85 1811 JLW Meaning of PROBE-FILE for direction output
C00705 00162 ∂09-Apr-85 1915 WHOLEY@CMU-CS-C.ARPA Compilation and package system
C00711 00163 ∂09-Apr-85 1958 RICHER@SUMEX-AIM.ARPA Re: Arg cont checking, optionals, keywords, etc
C00713 00164 ∂10-Apr-85 1012 DDYER@USC-ISIB.ARPA
C00714 00165 ∂10-Apr-85 1024 DCP@SCRC-VALLECITO.ARPA What are we talking about anyway?
C00717 00166 ∂10-Apr-85 1112 smh@mit-eddie.ARPA defstruct slot names
C00721 00167 ∂10-Apr-85 1156 FAHLMAN@CMU-CS-C.ARPA defstruct slot names
C00724 00168 ∂10-Apr-85 1159 RAM@CMU-CS-C.ARPA Meaning of PROBE-FILE for direction output
C00726 00169 ∂10-Apr-85 1222 RAM@CMU-CS-C.ARPA Compilation and package system
C00729 00170 ∂10-Apr-85 1504 REM@IMSSS interp .neq. compil, even in CL
C00733 00171 ∂10-Apr-85 1933 Moon@SCRC-STONY-BROOK.ARPA Compilation and package system
C00742 00172 ∂10-Apr-85 2006 GSB@MIT-MC Meaning of PROBE-FILE for direction output
C00744 00173 ∂10-Apr-85 2051 WHOLEY@CMU-CS-C.ARPA Compilation and package system
C00753 00174 ∂10-Apr-85 2137 KMP@SCRC-STONY-BROOK.ARPA Compilation and package system
C00765 00175 ∂11-Apr-85 0044 WHOLEY@CMU-CS-C.ARPA Compilation and package system
C00770 00176 ∂11-Apr-85 0607 greek@DEC-HUDSON PROBE-FILE
C00772 00177 ∂11-Apr-85 0649 greek@DEC-HUDSON A comment on packages (at the risk of being a fool)
C00774 00178 ∂11-Apr-85 1052 Moon@SCRC-QUABBIN.ARPA A comment on packages (at the risk of being a fool)
C00777 00179 ∂11-Apr-85 1103 OLDMAN@USC-ISI.ARPA Data General Common LISP
C00778 00180 ∂11-Apr-85 1128 KMP@SCRC-YUKON.ARPA PROBE-FILE
C00784 00181 ∂11-Apr-85 1156 FAHLMAN@CMU-CS-C.ARPA PROBE-FILE
C00787 00182 ∂11-Apr-85 1227 greek@DEC-HUDSON PROBE-FILE
C00788 00183 ∂11-Apr-85 1237 greek@DEC-HUDSON PROBE-FILE
C00789 00184 ∂11-Apr-85 1237 greek@DEC-HUDSON The compiler and packages.
C00792 00185 ∂11-Apr-85 1302 dzg@cmu-cs-spice.arpa Probe-file and errors
C00795 00186 ∂11-Apr-85 1613 Moon@SCRC-STONY-BROOK.ARPA PROBE-FILE
C00797 00187 ∂11-Apr-85 1702 Moon@SCRC-STONY-BROOK.ARPA The compiler and packages.
C00802 00188 ∂11-Apr-85 1852 masinter.pa@Xerox.ARPA Common Lisp should use lexical scoping
C00805 00189 ∂11-Apr-85 1932 masinter.pa@Xerox.ARPA probe-file
C00809 00190 ∂11-Apr-85 1937 FAHLMAN@CMU-CS-C.ARPA Common Lisp should use lexical scoping
C00811 00191 ∂11-Apr-85 2127 masinter.pa@Xerox.ARPA Re: PROBE-FILE
C00812 00192 ∂11-Apr-85 2139 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: PROBE-FILE
C00817 00193 ∂12-Apr-85 0701 greek@DEC-HUDSON A-Packaging we will go...
C00823 00194 ∂12-Apr-85 0704 FAHLMAN@CMU-CS-C.ARPA PROBE-FILE
C00825 00195 ∂12-Apr-85 1103 KMP@SCRC-STONY-BROOK.ARPA Probe-file and errors
C00828 00196 ∂12-Apr-85 1416 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: PROBE-FILE
C00833 00197 ∂12-Apr-85 1755 JLW Two PROBE-FILE questions
C00836 00198 ∂12-Apr-85 1822 card.pa@Xerox.ARPA Re: Arg cont checking, optionals, keywords, etc
C00838 00199 ∂12-Apr-85 1929 FAHLMAN@CMU-CS-C.ARPA Common Lisp should use lexical scoping
C00842 00200 ∂13-Apr-85 1410 HANDERSON@CMU-CS-C.ARPA Common Lisp should use lexical scoping
C00845 00201 ∂15-Apr-85 1712 Moon@SCRC-QUABBIN.ARPA Common Lisp should use lexical scoping
C00850 00202 ∂15-Apr-85 1713 Moon@SCRC-QUABBIN.ARPA A-Packaging we will go...
C00858 00203 ∂15-Apr-85 1718 DLW@SCRC-STONY-BROOK.ARPA probe-file
C00862 00204 ∂15-Apr-85 1718 DLW@SCRC-STONY-BROOK.ARPA Common Lisp should use lexical scoping
C00865 00205 ∂15-Apr-85 1719 DLW@SCRC-STONY-BROOK.ARPA PROBE-FILE
C00867 00206 ∂15-Apr-85 1843 FAHLMAN@CMU-CS-C.ARPA probe-file
C00869 00207 ∂16-Apr-85 0740 greek@DEC-HUDSON Packages and the Compiler
C00871 00208 ∂16-Apr-85 1433 DLW@SCRC-STONY-BROOK.ARPA Compilation and package system
C00878 00209 ∂16-Apr-85 1556 Moon@SCRC-STONY-BROOK.ARPA Compilation and package system
C00880 00210 ∂16-Apr-85 1808 DD60@CMU-CS-A.ARPA Package system
C00883 00211 ∂16-Apr-85 1921 FAHLMAN@CMU-CS-C.ARPA Compilation and package system
C00887 00212 ∂17-Apr-85 0800 DLW@SCRC-QUABBIN.ARPA Package system
C00889 00213 ∂17-Apr-85 0841 GSB@MIT-MC Re: Compilation and package system
C00892 00214 ∂17-Apr-85 1722 masinter.pa@Xerox.ARPA "lexical" packages
C00899 00215 ∂17-Apr-85 1752 FAHLMAN@CMU-CS-C.ARPA "lexical" packages
C00903 00216 ∂18-Apr-85 1013 DLW@SCRC-STONY-BROOK.ARPA Compilation and package system, an addendum
C00906 00217 ∂18-Apr-85 1253 REM%IMSSS.#Pup@SU-SCORE.ARPA What is a "file"? Lexical package usage?
C00909 00218 ∂18-Apr-85 1847 Moon@SCRC-STONY-BROOK.ARPA "lexical" packages
C00911 00219 ∂18-Apr-85 1911 KMP@MIT-MC "lexical" packages
C00912 00220 ∂19-Apr-85 2128 DLW@SCRC-STONY-BROOK.ARPA "lexical" packages
C00916 00221 ∂19-Apr-85 2133 DLW@SCRC-STONY-BROOK.ARPA "lexical" packages
C00919 00222 ∂21-Apr-85 0357 RAM@CMU-CS-C.ARPA Bug in CLM.
C00921 00223 ∂22-Apr-85 2230 JLW Bug in CLM?
C00923 00224 ∂23-Apr-85 0234 JLW Problems with packages?
C00929 00225 ∂24-Apr-85 0655 greek@DEC-HUDSON Code Generated by Macros
C00931 00226 ∂24-Apr-85 0714 RAM@CMU-CS-C.ARPA Bug in CLM?
C00933 00227 ∂24-Apr-85 0750 FAHLMAN@CMU-CS-C.ARPA Bug in CLM?
C00936 00228 ∂24-Apr-85 0836 WHOLEY@CMU-CS-C.ARPA Code Generated by Macros
C00939 00229 ∂24-Apr-85 0958 greek@DEC-HUDSON Code Generated by Macros
C00941 00230 ∂24-Apr-85 1208 DCP@STONY-BROOK.SCRC.Symbolics.COM Code Generated by Macros
C00945 00231 ∂24-Apr-85 1628 GSB@MIT-MC Code Generated by Macros
C00947 00232 ∂24-Apr-85 1750 Moon@STONY-BROOK.SCRC.Symbolics.COM When is a package name equivalent to a package?
C00950 00233 ∂24-Apr-85 1822 KMP@STONY-BROOK.SCRC.Symbolics.COM When is a package name equivalent to a package?
C00956 00234 ∂24-Apr-85 1829 Moon@STONY-BROOK.SCRC.Symbolics.COM Code Generated by Macros
C00959 00235 ∂24-Apr-85 1905 FAHLMAN@CMU-CS-C.ARPA When is a package name equivalent to a package?
C00962 00236 ∂24-Apr-85 1932 Moon@STONY-BROOK.SCRC.Symbolics.COM When is a package name equivalent to a package?
C00967 00237 ∂24-Apr-85 2057 Moon@STONY-BROOK.SCRC.Symbolics.COM Problems with packages?
C00973 00238 ∂25-Apr-85 0054 JLW When is a package name equivalent to a package?
C00975 00239 ∂25-Apr-85 0343 JLW More on (B): the editor's "reading" of files
C00979 00240 ∂25-Apr-85 0419 JLW What package are feature names resident in?
C00983 00241 ∂25-Apr-85 0642 greek@DEC-HUDSON Code Generated by Macros
C00985 00242 ∂25-Apr-85 1507 Moon@STONY-BROOK.SCRC.Symbolics.COM More on (B): the editor's "reading" of files
C00988 00243 ∂25-Apr-85 1523 fateman%ucbdali@Berkeley RPG's benchmarks coming out as an MIT press book
C00990 00244 ∂25-Apr-85 1935 FAHLMAN@CMU-CS-C.ARPA When is a package name equivalent to a package?
C00992 00245 ∂26-Apr-85 1211 RAM@CMU-CS-C.ARPA What package are feature names resident in?
C00994 00246 ∂26-Apr-85 1453 GSB@MIT-MC package names, consistency
C00996 00247 ∂27-Apr-85 1142 TIM@MIT-MC Editing multiple package files
C01001 00248 ∂28-Apr-85 1123 RPG Common Lisp song considered offensive?
C01005 00249 ∂28-Apr-85 1124 RPG Common Lisp song considered offensive?
C01008 00250 ∂28-Apr-85 1124 RPG Common Lisp song considered offensive?
C01011 00251 ∂28-Apr-85 1400 Moon@SCRC-STONY-BROOK.ARPA Any complete CL implementations??
C01014 00252 ∂28-Apr-85 2033 RPG Common Lisp song considered offensive?
C01017 00253 ∂29-Apr-85 1300 Moon@SCRC-VALLECITO.ARPA wimpy COERCE function
C01020 00254 ∂29-Apr-85 1714 RWK@SCRC-STONY-BROOK.ARPA More on (B): the editor's "reading" of files
C01023 00255 ∂30-Apr-85 0735 DLW@SCRC-STONY-BROOK.ARPA wimpy COERCE function
C01025 00256 ∂04-May-85 0838 RAM@CMU-CS-C.ARPA Misfeature: macros expanding into declarations
C01028 00257 ∂04-May-85 1209 FAHLMAN@CMU-CS-C.ARPA Misfeature: macros expanding into declarations
C01031 00258 ∂04-May-85 1529 TIM@MIT-MC Misfeature: macros expanding into declarations
C01038 00259 ∂04-May-85 1543 vanroggen@DEC-HUDSON macr --> declares
C01040 00260 ∂04-May-85 1549 RAM@CMU-CS-C.ARPA Misfeature: macros expanding into declarations
C01043 00261 ∂04-May-85 1557 RAM@CMU-CS-C.ARPA macr --> declares
C01045 00262 ∂05-May-85 0145 HEDRICK@RUTGERS.ARPA (setf (apply #'foo
C01047 00263 ∂05-May-85 0853 FAHLMAN@CMU-CS-C.ARPA macr --> declares
C01051 00264 ∂05-May-85 0909 RAM@CMU-CS-C.ARPA macr --> declares
C01053 00265 ∂05-May-85 0919 FAHLMAN@CMU-CS-C.ARPA Misfeature: macros expanding into declarations
C01057 00266 ∂05-May-85 0953 FAHLMAN@CMU-CS-C.ARPA macr --> declares
C01059 00267 ∂05-May-85 1036 fateman%ucbdali@Berkeley mysterious declarations off in left field
C01061 00268 ∂05-May-85 1112 FAHLMAN@CMU-CS-C.ARPA mysterious declarations off in left field
C01063 00269 ∂05-May-85 1633 KMP@SCRC-STONY-BROOK.ARPA mysterious declarations off in left field
C01068 00270 ∂05-May-85 1739 FAHLMAN@CMU-CS-C.ARPA mysterious declarations off in left field
C01071 00271 ∂05-May-85 1742 SOLEY@MIT-MC Misfeature: macros expanding into declarations
C01075 00272 ∂05-May-85 1826 REM@IMSSS Restrictions on what macros may call, to avoid needing to preload file
C01080 00273 ∂05-May-85 1837 MLY@MIT-MC Misfeature: macros expanding into declarations
C01086 00274 ∂05-May-85 1845 SOLEY@MIT-MC Misfeature: macros expanding into declarations
C01091 00275 ∂05-May-85 1849 SOLEY@MIT-MC Restrictions on what macros may call, to avoid needing to preload file
C01094 00276 ∂05-May-85 1948 FAHLMAN@CMU-CS-C.ARPA Misfeature: macros expanding into declarations
C01097 00277 ∂05-May-85 2001 GSB@MIT-MC (setf (apply #'foo ...) ...)
C01099 00278 ∂05-May-85 2252 HEDRICK@RUTGERS.ARPA Re: (setf (apply #'foo ...) ...)
C01100 00279 ∂06-May-85 0834 gls%AQUINAS@THINK.ARPA SETF of APPLY
C01103 00280 ∂06-May-85 0845 gls%AQUINAS@THINK.ARPA Macros -> declarations
C01106 00281 ∂06-May-85 0854 gls%AQUINAS@THINK.ARPA PROCLAIM and type declarations
C01108 00282 ∂06-May-85 0947 vanroggen@DEC-HUDSON macros --> declarations
C01109 00283 ∂06-May-85 0953 vanroggen@DEC-HUDSON local declarations
C01111 00284 ∂06-May-85 1043 vanroggen@DEC-HUDSON SETF APPLY ...
C01113 00285 ∂06-May-85 1053 WHOLEY@CMU-CS-C.ARPA (setf (apply #'foo ...) ...)
C01115 00286 ∂06-May-85 1148 FAHLMAN@CMU-CS-C.ARPA local declarations
C01117 00287 ∂06-May-85 1159 FAHLMAN@CMU-CS-C.ARPA SETF of APPLY
C01119 00288 ∂06-May-85 1235 Moon@SCRC-YUKON.ARPA SETF of APPLY
C01122 00289 ∂06-May-85 1241 OLDMAN@USC-ISI.ARPA defconstant vs. lexical variables
C01124 00290 ∂06-May-85 1347 gls%AQUINAS@THINK.ARPA local declarations
C01127 00291 ∂06-May-85 1444 Moon@SCRC-QUABBIN.ARPA Macros -> declarations
C01134 00292 ∂06-May-85 1642 KMP@SCRC-STONY-BROOK.ARPA Macros -> declarations
C01138 00293 ∂06-May-85 1721 WHOLEY@CMU-CS-C.ARPA Macros -> declarations
C01142 00294 ∂06-May-85 1744 HEDRICK@RUTGERS.ARPA SETF (APPLY
C01144 00295 ∂06-May-85 1745 KMP@SCRC-STONY-BROOK.ARPA Macros -> declarations
C01151 00296 ∂06-May-85 1801 WHOLEY@CMU-CS-C.ARPA Macros -> declarations
C01153 00297 ∂06-May-85 1804 Moon@SCRC-STONY-BROOK.ARPA SETF (APPLY
C01156 00298 ∂06-May-85 1830 HEDRICK@RUTGERS.ARPA Re: SETF (APPLY
C01158 00299 ∂06-May-85 1857 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations
C01160 00300 ∂07-May-85 1118 BSG@SCRC-RIVERSIDE.ARPA Macros -> declarations
C01163 00301 ∂07-May-85 1139 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations
C01168 00302 ∂07-May-85 1221 KMP@SCRC-STONY-BROOK.ARPA Macros -> declarations
C01177 00303 ∂07-May-85 1319 REM%IMSSS.#Pup@SU-SCORE.ARPA Read macros vs. macro-->declare
C01180 00304 ∂07-May-85 1350 KMP@SCRC-STONY-BROOK.ARPA Read macros vs. macro-->declare
C01185 00305 ∂07-May-85 1951 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations
C01188 00306 ∂07-May-85 2237 hoey@nrl-aic Re: SETF of APPLY
C01196 00307 ∂08-May-85 0835 JLW PARSE-BODY
C01198 00308 ∂08-May-85 0859 RWK@SCRC-STONY-BROOK.ARPA Macros -> declarations
C01202 00309 ∂08-May-85 0919 JLW ... point on a different point
C01204 00310 ∂08-May-85 1121 FAHLMAN@CMU-CS-C.ARPA ... point on a different point
C01206 00311 ∂08-May-85 1513 RPG Proposal
C01210 00312 ∂08-May-85 1843 FAHLMAN@CMU-CS-C.ARPA Proposal
C01215 00313 ∂08-May-85 2159 TIM@MIT-MC Lack of EQUALP hash tables
C01217 00314 ∂08-May-85 2246 RPG Fahlman's comments
C01219 00315 ∂09-May-85 0511 GJC@MIT-MC
C01222 00316 ∂09-May-85 0622 RAM@CMU-CS-C.ARPA Lack of EQUALP hash tables
C01224 00317 ∂09-May-85 0643 BSG@SCRC-STONY-BROOK.ARPA Macros -> declarations
C01227 00318 ∂09-May-85 0900 DCP@SCRC-STONY-BROOK.ARPA hash table types
C01230 00319 ∂09-May-85 0911 FAHLMAN@CMU-CS-C.ARPA Fahlman's comments
C01233 00320 ∂09-May-85 0929 GRISS%hp-hulk.csnet@csnet-relay.arpa Re: PARSE-BODY
C01235 00321 ∂09-May-85 1103 RPG Comments on ...
C01238 00322 ∂09-May-85 2101 FAHLMAN@CMU-CS-C.ARPA PARSE-BODY
C01241 00323 ∂09-May-85 2254 KMP@SCRC-STONY-BROOK.ARPA Macros -> declarations
C01250 00324 ∂09-May-85 2319 JLW READ-AN-DO-FILE-ATTRIBUTES
C01252 00325 ∂09-May-85 2356 JLW EQUALP hash tables (and more ...)
C01256 00326 ∂10-May-85 0017 JLW Y.A.R.I.M.: Macros inside DECLARE?
C01258 00327 ∂10-May-85 0146 hoey@nrl-aic Re: EQUALP hash tables (and more ...)
C01261 00328 ∂10-May-85 0906 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations
C01269 00329 ∂10-May-85 1057 REM@IMSSS Instead of read macros, how about one reserved-word for process-time macro?
C01274 00330 ∂10-May-85 1139 BSG@SCRC-STONY-BROOK.ARPA Y.A.R.I.M.: Macros inside DECLARE?
C01277 00331 ∂10-May-85 1239 BSG@SCRC-STONY-BROOK.ARPA Macros -> declarations
C01281 00332 ∂10-May-85 2005 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations
C01283 00333 ∂11-May-85 0635 FAHLMAN@CMU-CS-C.ARPA :-(
C01285 00334 ∂11-May-85 0759 FAHLMAN@CMU-CS-C.ARPA EQUALP hash tables (and more ...)
C01289 00335 ∂11-May-85 1229 WHOLEY@CMU-CS-C.ARPA EQUALP hash tables (and more ...)
C01294 00336 ∂11-May-85 1404 RWK@SCRC-STONY-BROOK.ARPA Macros -> declarations
C01301 00337 ∂11-May-85 2300 TIM@MIT-MC Macros -> declarations
C01305 00338 ∂12-May-85 0550 GJC@MIT-MC hash table types
C01308 00339 ∂12-May-85 1225 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: defconstant vs. lexical variables
C01311 00340 ∂12-May-85 1748 hoey@nrl-aic Re: EQUALP hash tables (and more ...)
C01313 00341 ∂12-May-85 2030 FAHLMAN@CMU-CS-C.ARPA EQUALP hash tables (and more ...)
C01316 00342 ∂13-May-85 0905 JLW YARIM and the adbmal example
C01318 00343 ∂13-May-85 0919 BSG@SCRC-STONY-BROOK.ARPA :-(
C01326 00344 ∂13-May-85 0930 BSG@SCRC-STONY-BROOK.ARPA YARIM and the adbmal example
C01330 00345 ∂13-May-85 1144 DCP%TENEX.SCRC@MIT-XX.ARPA hash table types
C01338 00346 ∂13-May-85 1145 DCP%TENEX.SCRC@MIT-XX.ARPA hash table types
C01347 00347 ∂14-May-85 0905 KESSLER@UTAH-20.ARPA &optional with &key
C01349 00348 ∂14-May-85 0933 gls@AQUINAS.ARPA &optional with &key
C01351 00349 ∂14-May-85 1002 RWK@SCRC-STONY-BROOK.ARPA &optional with &key
C01354 00350 ∂14-May-85 1655 REM@IMSSS Semantic question about closures
C01357 00351 ∂14-May-85 1858 RAM@CMU-CS-C.ARPA Semantic question about closures
C01363 00352 ∂14-May-85 2103 WHOLEY@CMU-CS-C.ARPA Apply-But-Last
C01365 00353 ∂15-May-85 1221 REM@IMSSS Another question about lexical closures
C01368 00354 ∂15-May-85 1233 MOON%TENEX.SCRC@MIT-XX.ARPA Validation
C01372 00355 ∂15-May-85 1331 RWK@SCRC-STONY-BROOK.ARPA Another question about lexical closures
C01377 00356 ∂15-May-85 1332 RWK@SCRC-STONY-BROOK.ARPA Another question about lexical closures
C01383 00357 ∂15-May-85 1354 STENGER%ti-csl.csnet@csnet-relay.arpa adding PARSE-BODY primitive
C01385 00358 ∂15-May-85 1643 J.Dalton%edxa@Ucl-Cs.ARPA lexical closures
C01390 00359 ∂01-Jun-85 0859 RPG Preposterousness
C01393 00360 ∂16-May-85 1845 Masinter.pa@Xerox.ARPA Re: Macros -> declarations
C01395 00361 ∂16-May-85 1847 FAHLMAN@CMU-CS-C.ARPA Preposterousness
C01400 00362 ∂16-May-85 1946 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations
C01403 00363 ∂16-May-85 2007 GRISS%hp-hulk.csnet@csnet-relay.arpa Collections of CL tests and validations
C01405 00364 ∂16-May-85 2346 RPG Benchmarking
C01406 00365 ∂17-May-85 0129 REM@IMSSS Property lists
C01408 00366 ∂17-May-85 0544 KMP@SCRC-QUABBIN.ARPA Property lists
C01411 00367 ∂17-May-85 0621 KMP@SCRC-QUABBIN.ARPA Macros -> declarations
C01418 00368 ∂17-May-85 0731 JLW ∂10-May-85 0146 hoey@nrl-aic Re: EQUALP hash tables (and more ...)
C01425 00369 ∂17-May-85 0735 JLW SXHASH on circular structures?
C01429 00370 ∂17-May-85 0803 gls%AQUINAS@THINK.ARPA Poor excuse for packages
C01431 00371 ∂17-May-85 0803 Masinter.pa@Xerox.ARPA Re: Macros -> declarations
C01435 00372 ∂17-May-85 0807 JLW EQUALP hash tables
C01440 00373 ∂17-May-85 0841 JLW hash table types
C01442 00374 ∂17-May-85 0905 BSG@SCRC-STONY-BROOK.ARPA Poor excuse for packages
C01445 00375 ∂17-May-85 0905 KMP@SCRC-STONY-BROOK.ARPA Poor excuse for packages
C01450 00376 ∂17-May-85 0905 Cassels@SCRC-STONY-BROOK.ARPA Poor excuse for packages
C01455 00377 ∂17-May-85 0944 smh@mit-eddie.ARPA Re: Poor excuse for packages
C01459 00378 ∂17-May-85 0957 hoey@nrl-aic SXHASH and EQ hash tables
C01462 00379 ∂17-May-85 0958 gls%AQUINAS@THINK.ARPA Poor excuse for a Quux
C01464 00380 ∂17-May-85 0959 gls%AQUINAS@THINK.ARPA Backquote idioms
C01467 00381 ∂17-May-85 1045 @MIT-REAGAN.ARPA:Soley@MIT-MC.ARPA Macros -> declarations
C01470 00382 ∂17-May-85 1158 HEDRICK@RUTGERS.ARPA special declaration
C01473 00383 ∂17-May-85 1815 Moon@SCRC-STONY-BROOK.ARPA EQUALP hash tables (and more ...)
C01476 00384 ∂17-May-85 1831 Moon@SCRC-STONY-BROOK.ARPA Macros -> declarations
C01485 00385 ∂17-May-85 2051 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations
C01488 00386 ∂18-May-85 0815 KMP@SCRC-STONY-BROOK.ARPA Macros -> declarations
C01497 00387 ∂18-May-85 0932 masinter.PA@Xerox.ARPA uses for specials
C01499 00388 ∂18-May-85 1112 KMP@SCRC-STONY-BROOK.ARPA DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form"
C01506 00389 ∂18-May-85 1156 WHOLEY@CMU-CS-C.ARPA Macros -> declarations
C01509 00390 ∂18-May-85 1352 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations
C01518 00391 ∂18-May-85 1406 FAHLMAN@CMU-CS-C.ARPA DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form"
C01522 00392 ∂18-May-85 1413 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations (oops!)
C01524 00393 ∂18-May-85 1916 GSB@MIT-MC Re: EQUALP hash tables (and more ...)
C01528 00394 ∂19-May-85 0926 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special
C01539 00395 ∂19-May-85 0930 DD60@CMU-CS-A.ARPA user hash tables
C01544 00396 ∂19-May-85 1246 FAHLMAN@CMU-CS-C.ARPA Yellow pages
C01548 00397 ∂20-May-85 0707 DCP@SCRC-STONY-BROOK.ARPA Macros -> declarations
C01552 00398 ∂20-May-85 0721 DCP@SCRC-STONY-BROOK.ARPA hash table types
C01556 00399 ∂20-May-85 1012 gls%AQUINAS@THINK.ARPA Backquote idioms
C01558 00400 ∂20-May-85 1328 KMP@SCRC-VALLECITO.ARPA "Special Operator" vs "Special Form"
C01564 00401 ∂20-May-85 1810 GSB@MIT-MC hash table types -- ROT
C01566 00402 ∂20-May-85 1844 GSB@MIT-MC terminology
C01568 00403 ∂20-May-85 2252 REM@IMSSS FORM vs. FUNCTION etc.
C01571 00404 ∂21-May-85 0801 RWK@SCRC-STONY-BROOK.ARPA Backquote idioms
C01577 00405 ∂21-May-85 0848 JAR@MIT-MC "Special Operator"
C01579 00406 ∂21-May-85 2211 Moon@SCRC-VALLECITO.ARPA terminology
C01581 00407 ∂22-May-85 0805 gls%AQUINAS@THINK.ARPA Backquote idioms
C01593 00408 ∂22-May-85 0853 DCP@SCRC-STONY-BROOK.ARPA Backquote idioms
C01595 00409 ∂22-May-85 0906 BSG@SCRC-RIVERSIDE.ARPA Backquote idioms
C01599 00410 ∂22-May-85 1010 DCP@SCRC-STONY-BROOK.ARPA Backquote idioms
C01605 00411 ∂22-May-85 1012 DDYER@USC-ISIB.ARPA Local SPECIAL declarations
C01607 00412 ∂22-May-85 1142 smh@mit-eddie.ARPA Re: Backquote idioms
C01611 00413 ∂22-May-85 1155 gls@AQUINAS.ARPA Backquote idioms
C01614 00414 ∂22-May-85 1206 Masinter.pa@Xerox.ARPA Backquote idioms
C01616 00415 ∂22-May-85 1213 KMP@SCRC-STONY-BROOK.ARPA Re: Backquote idioms
C01622 00416 ∂22-May-85 1343 DCP@SCRC-STONY-BROOK.ARPA Re: Backquote idioms
C01625 00417 ∂22-May-85 1600 RWK@SCRC-STONY-BROOK.ARPA Backquote idioms
C01628 00418 ∂22-May-85 1927 Moon@SCRC-STONY-BROOK.ARPA Special form terminology
C01631 00419 ∂22-May-85 1927 DLW@SCRC-STONY-BROOK.ARPA Macros -> declarations
C01635 00420 ∂22-May-85 2057 RAM@CMU-CS-C.ARPA Adjustable and displaced arrays
C01638 00421 ∂22-May-85 2108 DLW@SCRC-STONY-BROOK.ARPA EQUALP hash tables (and more ...)
C01641 00422 ∂23-May-85 0130 STEINER@RUTGERS.ARPA Does FORMAT handle multiple values
C01643 00423 ∂23-May-85 0157 RAM@CMU-CS-C.ARPA Does FORMAT handle multiple values
C01645 00424 ∂23-May-85 0503 RAM@CMU-CS-C.ARPA Get-Setf-Method
C01646 00425 ∂23-May-85 0657 greek@DEC-HUDSON Adjusting Displaced Arrays
C01647 00426 ∂23-May-85 0747 gls%AQUINAS@THINK.ARPA Does FORMAT handle multiple values
C01649 00427 ∂23-May-85 0757 gls%AQUINAS@THINK.ARPA Adjustable and displaced arrays
C01654 00428 ∂23-May-85 0818 gls%AQUINAS@THINK.ARPA Rules of the game
C01660 00429 ∂23-May-85 0841 fateman%ucbdali@Berkeley rules of the game
C01663 00430 ∂23-May-85 0939 GRISS%hp-hulk.csnet@csnet-relay.arpa Re: Local SPECIAL declarations
C01665 00431 ∂23-May-85 1038 RAM@CMU-CS-C.ARPA Adjustable and displaced arrays
C01668 00432 ∂23-May-85 1113 DLW@SCRC-STONY-BROOK.ARPA Re: Backquote idioms
C01670 00433 ∂23-May-85 1336 DCP@SCRC-STONY-BROOK.ARPA Adjustable and displaced arrays
C01673 00434 ∂23-May-85 1456 RPG Yellow pages
C01675 00435 ∂23-May-85 1539 STEINER@RUTGERS.ARPA Re: Does FORMAT handle multiple values
C01680 00436 ∂23-May-85 1819 GSB@MIT-MC Get-Setf-Method
C01681 00437 ∂23-May-85 2022 DLW@SCRC-STONY-BROOK.ARPA Fahlman's comments
C01684 00438 ∂23-May-85 2302 GSB@MIT-MC Re: Adjustable and displaced arrays
C01690 00439 ∂24-May-85 0909 DLW@SCRC-STONY-BROOK.ARPA Rules of the game
C01693 00440 ∂24-May-85 0955 GRISS%hp-hulk.csnet@csnet-relay.arpa Addendum/Erratum
C01695 00441 ∂24-May-85 1030 gls%AQUINAS@THINK.ARPA Rules of the game and stability
C01699 00442 ∂24-May-85 1300 gls%AQUINAS@THINK.ARPA Addendum/Erratum
C01707 00443 ∂27-May-85 1105 RAM@CMU-CS-C.ARPA Does Defmacro establish a block?
C01709 00444 ∂27-May-85 1225 DLW@SCRC-STONY-BROOK.ARPA Does Defmacro establish a block?
C01711 00445 ∂28-May-85 0742 greek@DEC-HUDSON Rules of the Game
C01713 00446 ∂28-May-85 0822 greek@DEC-HUDSON Adjusting displaced arrays.
C01715 00447 ∂28-May-85 0946 DCP@SCRC-STONY-BROOK.ARPA Adjusting displaced arrays.
C01719 00448 ∂28-May-85 1439 masinter.pa@Xerox.ARPA programs writing backquote
C01721 00449 ∂28-May-85 1450 masinter.pa@Xerox.ARPA Re: Rules of the game and stability
C01722 00450 ∂28-May-85 1515 KMP@SCRC-STONY-BROOK.ARPA programs writing backquote
C01726 00451 ∂28-May-85 1532 MASINTER@SUMEX-AIM.ARPA (duplicate) programs writing backquote
C01729 00452 ∂29-May-85 0005 REM@IMSSS
C01733 00453 ∂29-May-85 0709 greek@DEC-HUDSON Internal representation of backquotes
C01735 00454 ∂29-May-85 1246 greek@DEC-HUDSON Internal representation of backquotes
C01737 00455 ∂29-May-85 1257 DCP@SCRC-STONY-BROOK.ARPA programs writing backquote
C01743 00456 ∂29-May-85 1257 DLW@SCRC-STONY-BROOK.ARPA Re: Rules of the game and stability
C01745 00457 ∂29-May-85 1445 gls@AQUINAS.ARPA Re: Rules of the game and stability
C01748 00458 ∂31-May-85 0926 DCP@SCRC-STONY-BROOK.ARPA CLtL Index
C01750 00459 ∂31-May-85 1440 hplabs!perdue%hplabs.csnet@csnet-relay.arpa Re: Programs writing backquote
C01752 00460 ∂02-Jun-85 0802 FAHLMAN@CMU-CS-C.ARPA Programs writing backquote
C01755 00461 ∂02-Jun-85 1058 FAHLMAN@CMU-CS-C.ARPA Rules of the game and stability
C01761 00462 ∂02-Jun-85 1220 FAHLMAN@CMU-CS-C.ARPA Get-Setf-Method
C01763 00463 ∂03-Jun-85 0520 JLW Explicit definition of backquote
C01769 00464 ∂03-Jun-85 0624 greek@DEC-HUDSON Programs writing backquotes
C01770 00465 ∂03-Jun-85 0710 KMP@SCRC-STONY-BROOK.ARPA Programs writing backquotes
C01772 00466 ∂03-Jun-85 0945 vanroggen@DEC-HUDSON read macros
C01774 00467 ∂03-Jun-85 1925 GSB@MIT-MC.ARPA Get-Setf-Method
C01776 00468 ∂05-Jun-85 1328 gls@THINK.ARPA common lisp- &environment objects
C01778 00469 ∂05-Jun-85 1904 FAHLMAN@CMU-CS-C.ARPA common lisp- &environment objects
C01781 00470 ∂05-Jun-85 1921 FAHLMAN@CMU-CS-C.ARPA common lisp- &environment objects
C01783 00471 ∂06-Jun-85 0543 JLW Degenerate array axes
C01786 00472 ∂06-Jun-85 0740 gls@THINK.ARPA Degenerate array axes
C01791 00473 ∂06-Jun-85 0809 FAHLMAN@CMU-CS-C.ARPA Degenerate array axes
C01794 00474 ∂06-Jun-85 1001 FAHLMAN@CMU-CS-C.ARPA Degenerate array axes
C01797 00475 ∂06-Jun-85 1021 MLY@MIT-MC.ARPA Degenerate array axes -- really array printing.
C01800 00476 ∂06-Jun-85 1230 greek@DEC-HUDSON Arrays with zero dimensions.
C01801 00477 ∂06-Jun-85 2212 wilensky%ucbdali@Berkeley Common LISP terminology
C01812 00478 ∂07-Jun-85 0651 gls@THINK.ARPA Arrays with zero dimensions.
C01814 00479 ∂07-Jun-85 0933 greek@DEC-HUDSON Arrays with Zero Dimensions
C01815 00480 ∂09-Jun-85 1707 DCP@SCRC-YUKON.ARPA Arrays with zero dimensions.
C01817 00481 ∂09-Jun-85 1707 DCP@SCRC-YUKON.ARPA common lisp- &environment objects
C01821 00482 ∂09-Jun-85 1756 ima!inmet!norman@cca-unix
C01822 00483 ∂09-Jun-85 2016 FAHLMAN@CMU-CS-C.ARPA common lisp- &environment objects
C01828 00484 ∂10-Jun-85 0357 DCP@SCRC-STONY-BROOK.ARPA common lisp- &environment objects
C01837 00485 ∂10-Jun-85 0646 FAHLMAN@CMU-CS-C.ARPA common lisp- &environment objects
C01843 00486 ∂10-Jun-85 0702 REM@IMSSS Environment-objects don't exist in CL according to manual
C01847 00487 ∂10-Jun-85 0748 FAHLMAN@CMU-CS-C.ARPA Environment-objects don't exist in CL according to manual
C01851 00488 ∂10-Jun-85 1040 HEDRICK@RUTGERS.ARPA extent of environments
C01854 00489 ∂10-Jun-85 1108 greek@DEC-HUDSON Scott's observation on MACROLET
C01855 00490 ∂10-Jun-85 1200 DCP@SCRC-STONY-BROOK.ARPA common lisp- &environment objects
C01859 00491 ∂10-Jun-85 2256 @MIT-MC:BROOKS@MIT-OZ function type specifiers
C01861 00492 ∂11-Jun-85 1043 RWW using lower case
C01862 00493 ∂11-Jun-85 1245 Moon@SCRC-STONY-BROOK.ARPA Adjustable and displaced arrays
C01872 00494 ∂11-Jun-85 1247 FAHLMAN@CMU-CS-C.ARPA using lower case
C01874 00495 ∂11-Jun-85 1259 Moon@SCRC-STONY-BROOK.ARPA Degenerate array axes
C01877 00496 ∂11-Jun-85 1311 Moon@SCRC-STONY-BROOK.ARPA common lisp- &environment objects
C01881 00497 ∂11-Jun-85 1316 Moon@SCRC-STONY-BROOK.ARPA Does Defmacro establish a block?
C01884 00498 ∂11-Jun-85 1317 gls@THINK.ARPA Environment-objects don't exist in CL according to manual
C01886 00499 ∂11-Jun-85 1817 FAHLMAN@CMU-CS-C.ARPA Does Defmacro establish a block?
C01889 00500 ∂11-Jun-85 1819 FAHLMAN@CMU-CS-C.ARPA common lisp- &environment objects
C01891 00501 ∂11-Jun-85 1825 FAHLMAN@CMU-CS-C.ARPA Degenerate array axes
C01893 00502 ∂11-Jun-85 1842 FAHLMAN@CMU-CS-C.ARPA Adjustable and displaced arrays
C01896 00503 ∂11-Jun-85 2048 Moon@SCRC-STONY-BROOK.ARPA Does Defmacro establish a block?
C01899 00504 ∂11-Jun-85 2052 Moon@SCRC-STONY-BROOK.ARPA Adjustable and displaced arrays
C01903 00505 ∂12-Jun-85 0417 walton%ll-xn.arpa@ll-xn.arpa Two suggestions on array adjustability.
C01907 00506 ∂12-Jun-85 0557 greek@DEC-HUDSON Using #.(MAKE-ARRAY ...
C01909 00507 ∂12-Jun-85 0630 greek@DEC-HUDSON Adjusting Displaced Arrays
C01912 00508 ∂12-Jun-85 0928 gls@THINK.ARPA Adjusting Displaced Arrays
C01915 00509 ∂12-Jun-85 0959 BSG@SCRC-STONY-BROOK.ARPA Using #.(MAKE-ARRAY ...
C01918 00510 ∂12-Jun-85 1225 greek@DEC-HUDSON Printing Arrays with #.
C01919 00511 ∂12-Jun-85 1312 REM@IMSSS Test suite to say what manual is confusing about
C01921 00512 ∂12-Jun-85 1339 REM@IMSSS Printing of displaced/shared arrays
C01924 00513 ∂12-Jun-85 1353 AS%hp-hulk.csnet@csnet-relay.arpa Re: Does Defmacro establish a block?
C01927 00514 ∂12-Jun-85 1459 RAM@CMU-CS-C.ARPA Does Defmacro establish a block?
C01929 00515 ∂12-Jun-85 1704 @MIT-MC.ARPA:BROOKS@MIT-OZ declaration pervasiveness.
C01931 00516 ∂13-Jun-85 0542 BSG@SCRC-STONY-BROOK.ARPA Re: Does Defmacro establish a block?
C01933 00517 ∂13-Jun-85 0821 DCP@SCRC-STONY-BROOK.ARPA declaration pervasiveness.
C01937 00518 ∂13-Jun-85 0933 FAHLMAN@CMU-CS-C.ARPA declaration pervasiveness.
C01940 00519 ∂13-Jun-85 0935 @MIT-MC.ARPA:BROOKS@MIT-OZ Re: declaration pervasiveness.
C01943 00520 ∂13-Jun-85 1139 gls@THINK.ARPA declaration pervasiveness.
C01948 00521 ∂13-Jun-85 1246 @MIT-MC.ARPA:BROOKS@MIT-OZ Re: declaration pervasiveness.
C01952 00522 ∂13-Jun-85 1428 AS%hp-hulk.csnet@csnet-relay.arpa conflicting declarations
C01955 00523 ∂13-Jun-85 1447 FAHLMAN@CMU-CS-C.ARPA conflicting declarations
C01957 00524 ∂13-Jun-85 1942 Moon@SCRC-STONY-BROOK.ARPA What package are feature names resident in?
C01965 00525 ∂14-Jun-85 0610 greek@DEC-HUDSON What's in *FEATURES*?
C01967 00526 ∂14-Jun-85 0900 gls@THINK.ARPA [hpfclp!paul%hplabs.csnet: LCM]
C01970 00527 ∂14-Jun-85 1010 Moon@SCRC-STONY-BROOK.ARPA What's in *FEATURES*?
C01974 00528 ∂14-Jun-85 1120 KMP@SCRC-STONY-BROOK.ARPA What's in *FEATURES*?
C01981 00529 ∂14-Jun-85 1317 greek@DEC-HUDSON Putting features in the keyword package.
C01984 00530 ∂14-Jun-85 1439 REM@IMSSS Features in keyword package? Yes.
C01987 00531 ∂14-Jun-85 1503 Masinter.pa@Xerox.ARPA What #+rmhackery a good idea #-rmhackery utter nonsense
C01989 00532 ∂14-Jun-85 1810 DCP@SCRC-STONY-BROOK.ARPA What #+rmhackery a good idea #-rmhackery utter nonsense
C01994 00533 ∂14-Jun-85 1846 FAHLMAN@CMU-CS-C.ARPA features
C01998 00534 ∂14-Jun-85 2043 KMP@SCRC-STONY-BROOK.ARPA features
C02005 00535 ∂15-Jun-85 1859 Masinter.pa@Xerox.ARPA Re: What #+rmhackery a good idea #-rmhackery utter nonsense
C02007 00536 ∂16-Jun-85 0600 DCP@SCRC-STONY-BROOK.ARPA Re: What #+rmhackery a good idea #-rmhackery utter nonsense
C02013 00537 ∂16-Jun-85 1300 KMP@SCRC-STONY-BROOK.ARPA Re: What #+rmhackery a good idea #-rmhackery utter nonsense
C02018 00538 ∂17-Jun-85 0022 hplabs!perdue%hplabs.csnet@csnet-relay.arpa Interesting Common LISP mail
C02024 00539 ∂17-Jun-85 0814 greek@DEC-HUDSON Features
C02028 00540 ∂17-Jun-85 0822 gls@THINK.ARPA Features in keyword package? Yes.
C02031 00541 ∂17-Jun-85 0840 RAM@CMU-CS-C.ARPA With-Open-File :if-does-not-exist nil
C02033 00542 ∂17-Jun-85 0903 gls@THINK.ARPA What #+rmhackery a good idea #-rmhackery utter nonsense
C02038 00543 ∂17-Jun-85 0912 gls@THINK.ARPA #+who You #-who I #-who can't #+who won't believe this #-who great #+who complete #+who crock #-who feature
C02041 00544 ∂17-Jun-85 0923 smh@mit-eddie.ARPA Re: Features
C02043 00545 ∂17-Jun-85 1004 greek@DEC-HUDSON Features.
C02045 00546 ∂17-Jun-85 1007 greek@DEC-HUDSON WITH-OPEN-FILE
C02046 00547 ∂17-Jun-85 1032 DLW@SCRC-QUABBIN.ARPA With-Open-File :if-does-not-exist nil
C02048 00548 ∂17-Jun-85 1033 DLW@SCRC-QUABBIN.ARPA With-Open-File :if-does-not-exist nil
C02050 00549 ∂17-Jun-85 1130 REM@IMSSS Recant: features don't belong in keyword package
C02053 00550 ∂17-Jun-85 1416 REM@IMSSS Unrecant
C02056 00551 ∂17-Jun-85 1459 hplabs!perdue%hplabs.csnet@csnet-relay.arpa Botched mail message
C02065 00552 ∂17-Jun-85 1533 DLW@SCRC-STONY-BROOK.ARPA features
C02067 00553 ∂17-Jun-85 1619 J.Dalton%edxa@ucl-cs.ARPA flat name space for pkg names
C02070 00554 ∂17-Jun-85 2039 FAHLMAN@CMU-CS-C.ARPA flat name space for pkg names
C02074 00555 ∂18-Jun-85 0636 greek@DEC-HUDSON Features.
C02076 00556 ∂18-Jun-85 0709 REM@IMSSS No change needed for name-domains in package-name space
C02079 00557 ∂18-Jun-85 0733 FAHLMAN@CMU-CS-C.ARPA No change needed for name-domains in package-name space
C02082 00558 ∂18-Jun-85 0900 DCP@SCRC-QUABBIN.ARPA Features
C02088 00559 ∂19-Jun-85 0716 greek@DEC-HUDSON Common LISP Registrar
C02089 00560 ∂20-Jun-85 0645 greek@DEC-HUDSON Common LISP Registrar
C02090 00561 ∂20-Jun-85 0709 DCP@SCRC-STONY-BROOK.ARPA Common LISP Registrar
C02093 00562 ∂20-Jun-85 0832 FAHLMAN@CMU-CS-C.ARPA Common LISP Registrar
C02097 00563 ∂20-Jun-85 1107 RWK@SCRC-STONY-BROOK.ARPA Common LISP Registrar
C02101 00564 ∂20-Jun-85 1202 OLDMAN@USC-ISI.ARPA make-string-output-stream
C02102 00565 ∂20-Jun-85 1521 Moon@SCRC-STONY-BROOK.ARPA What package are feature names resident in?
C02105 00566 ∂20-Jun-85 1752 FAHLMAN@CMU-CS-C.ARPA What package are feature names resident in?
C02107 00567 ∂21-Jun-85 0609 greek@DEC-HUDSON Features & Common LISP Registrar
C02109 00568 ∂21-Jun-85 0807 greek@DEC-HUDSON Proposal for Common LISP Registrar
C02119 00569 ∂21-Jun-85 1656 FAHLMAN@CMU-CS-C.ARPA Proposal for Common LISP Registrar
C02123 00570 ∂23-Jun-85 1502 JLW What package are feature names resident in?
C02126 00571 ∂23-Jun-85 1519 JLW Need for #+ and #-
C02128 00572 ∂24-Jun-85 0643 greek@DEC-HUDSON Common LISP Registry
C02130 00573 ∂24-Jun-85 1929 STEINER@RU-BLUE.ARPA Dribble and *error-output*
C02132 00574 ∂24-Jun-85 2028 FAHLMAN@CMU-CS-C.ARPA Dribble and *error-output*
C02134 00575 ∂25-Jun-85 0511 RAM@CMU-CS-C.ARPA Dribble and *error-output*
C02136 00576 ∂25-Jun-85 1325 hplabs!Snyder%hplabs.csnet@csnet-relay.arpa feature names
C02138 00577 ∂26-Jun-85 0940 Moon@SCRC-STONY-BROOK.ARPA char-equal of control characters
C02141 00578 ∂26-Jun-85 1527 Fischer.pa@Xerox.ARPA Adjustable and displaced arrays (summary)
C02146 00579 ∂26-Jun-85 1800 FAHLMAN@CMU-CS-C.ARPA char-equal of control characters
C02150 00580 ∂26-Jun-85 1942 Moon@SCRC-STONY-BROOK.ARPA char-equal of control characters
C02153 00581 ∂26-Jun-85 1959 FAHLMAN@CMU-CS-C.ARPA char-equal of control characters
C02156 00582 ∂26-Jun-85 2009 Moon@SCRC-STONY-BROOK.ARPA Adjustable and displaced arrays (summary)
C02158 00583 ∂27-Jun-85 0653 greek@DEC-HUDSON Comments on Array Summary.
C02161 00584 ∂28-Jun-85 1037 KMP@SCRC-STONY-BROOK.ARPA feature names
C02165 00585 ∂28-Jun-85 1415 Fischer.pa@Xerox.ARPA Re: Comments on Array Summary.
C02168 00586 ∂01-Jul-85 0803 FAHLMAN@CMU-CS-C.ARPA Comments on Array Summary.
C02170 00587 ∂01-Jul-85 0854 DLW@SCRC-STONY-BROOK.ARPA Unable to deliver letter
C02176 00588 ∂01-Jul-85 1118 FAHLMAN@CMU-CS-C.ARPA Unable to deliver letter
C02178 00589 ∂01-Jul-85 1321 greek@DEC-HUDSON Common LISP Registry
C02180 00590 ∂04-Jul-85 1249 Kahn.pa@Xerox.ARPA multiple slot descriptions of the same slot in a DEFSTRUCT
C02182 00591 ∂05-Jul-85 1317 Moon@SCRC-STONY-BROOK.ARPA multiple slot descriptions of the same slot in a DEFSTRUCT
C02184 00592 ∂05-Jul-85 1559 Masinter.pa@Xerox.ARPA Re: multiple slot descriptions of the same slot in a DEFSTRUCT
C02186 00593 ∂11-Jul-85 0917 Gall.HIS←Guest@MIT-MULTICS.ARPA flet and labels
C02188 00594 ∂11-Jul-85 1033 Moon@SCRC-STONY-BROOK.ARPA flet and labels
C02190 00595 ∂11-Jul-85 1225 RPG Archives
C02191 00596 ∂12-Jul-85 0937 marick@GSWD-VMS Proposal for a UNIX subgroup.
C02193 00597 ∂12-Jul-85 1036 fateman%ucbdali@Berkeley Re: Proposal for a UNIX subgroup.
C02195 00598 ∂12-Jul-85 1107 FAHLMAN@CMU-CS-C.ARPA Proposal for a UNIX subgroup.
C02198 00599 ∂21-Jul-85 1743 RPG Simple Minds
C02199 00600 ∂22-Jul-85 1043 gls@THINK-AQUINAS.ARPA Simple Minds
C02201 00601 ∂26-Jul-85 1103 KMP@SCRC-STONY-BROOK.ARPA CHAR-BIT
C02206 00602 ∂26-Jul-85 1159 KMP@SCRC-STONY-BROOK.ARPA Clearing the screen and other such things.
C02216 00603 ∂26-Jul-85 1215 KMP@SCRC-STONY-BROOK.ARPA Does READ-CHAR echo?
C02219 00604 ∂26-Jul-85 1421 RWK@SCRC-YUKON.ARPA Does READ-CHAR echo?
C02223 00605 ∂26-Jul-85 1605 HAUG%ti-csl.csnet@csnet-relay.arpa labels
C02225 00606 ∂26-Jul-85 1618 mips!earl@Glacier Does READ-CHAR echo?
C02228 00607 ∂26-Jul-85 1638 mips!earl@Glacier Clearing the screen and other such things.
C02231 00608 ∂26-Jul-85 2357 TIM@MIT-MC.ARPA labels
C02233 00609 ∂27-Jul-85 0210 TIM@MIT-MC.ARPA Clearing the screen and other such things.
C02240 00610 ∂27-Jul-85 1137 fateman%ucbdali@Berkeley Re: Clearing the screen and other such things.
C02242 00611 ∂27-Jul-85 1334 TIM@MIT-MC.ARPA Clearing the screen and other such things.
C02245 00612 ∂27-Jul-85 2111 WHOLEY@CMU-CS-C.ARPA Clearing the screen and other such things.
C02250 00613 ∂28-Jul-85 1430 RAM@CMU-CS-C.ARPA Clearing the screen and other such things.
C02253 00614 ∂28-Jul-85 2205 TIM@MIT-MC.ARPA Clearing the screen and other such things.
C02256 00615 ∂29-Jul-85 0136 RAM@CMU-CS-C.ARPA Clearing the screen and other such things.
C02259 00616 ∂29-Jul-85 0558 BSG@SCRC-STONY-BROOK.ARPA Clearing the screen and other such things.
C02264 00617 ∂29-Jul-85 0707 greek@DEC-HUDSON A comment on our community.
C02265 00618 ∂29-Jul-85 0708 greek@DEC-HUDSON A comment on our community.
C02266 00619 ∂29-Jul-85 0708 greek@DEC-HUDSON A comment on our community.
C02267 00620 ∂29-Jul-85 0709 greek@DEC-HUDSON A comment on our community.
C02271 00621 ∂29-Jul-85 0954 gls@THINK-AQUINAS.ARPA Clearing the screen and other such things.
C02273 00622 ∂29-Jul-85 1048 TIM@MIT-MC.ARPA Clearing the screen and other such things.
C02276 00623 ∂29-Jul-85 1235 Fischer.pa@Xerox.ARPA RE: Clearing the screen and other such things.
C02278 00624 ∂29-Jul-85 1752 Moon@SCRC-STONY-BROOK.ARPA Does READ-CHAR echo?
C02286 00625 ∂29-Jul-85 2307 DDYER@USC-ISIB.ARPA Clearing the screen etc.
C02289 00626 ∂30-Jul-85 0138 masinter.pa@Xerox.ARPA Re: CHAR-BIT
C02292 00627 ∂30-Jul-85 0206 masinter.pa@Xerox.ARPA Re: Clearing the screen etc.
C02294 00628 ∂30-Jul-85 0643 greek@DEC-HUDSON Terminal operations.
C02297 00629 ∂30-Jul-85 0756 RAM@CMU-CS-C.ARPA CHAR-BIT
C02301 00630 ∂30-Jul-85 1209 MEEHAN@YALE.ARPA Re: Clearing the screen and other such things.
C02304 00631 ∂30-Jul-85 2034 RWK@SCRC-STONY-BROOK.ARPA Terminal operations.
C02308 00632 ∂31-Jul-85 1107 DCP@SCRC-STONY-BROOK.ARPA Clearing the screen and other such things.
C02312 00633 ∂05-Aug-85 0938 KESSLER@UTAH-20.ARPA Lambda Keywords
C02313 00634 ∂05-Aug-85 1010 FAHLMAN@CMU-CS-C.ARPA Lambda Keywords
C02315 00635 ∂06-Aug-85 1356 Bobrow.pa@Xerox.ARPA defstruct syntax
C02317 00636 ∂06-Aug-85 1421 gls@THINK-AQUINAS.ARPA defstruct syntax
C02319 00637 ∂07-Aug-85 1155 WHOLEY@CMU-CS-C.ARPA CLTL tablos and indexos (not really typos)
C02321 00638 ∂07-Aug-85 1944 KSH@MIT-MC.ARPA
C02322 00639 ∂08-Aug-85 0714 KMP@SCRC-STONY-BROOK.ARPA Disallowing NIL as a feature
C02325 00640 ∂12-Aug-85 1551 Masinter.pa@Xerox.ARPA CommonLoops: Merging Common Lisp Object-Oriented Programming
C02329 00641 ∂13-Aug-85 1240 SQUIRES@USC-ISI.ARPA Re: CommonLoops: Merging Common Lisp Object-Oriented Program...
C02331 00642 ∂15-Aug-85 1518 nmm%computer-lab.cambridge.ac.uk@ucl-cs.ARPA
C02333 00643 ∂16-Aug-85 0056 franz!jkf@Berkeley endp or not consp
C02335 00644 ∂16-Aug-85 1200 robbins@DEC-HUDSON with-output-to-string query
C02337 00645 ∂16-Aug-85 1240 FAHLMAN@CMU-CS-C.ARPA with-output-to-string query
C02340 00646 ∂16-Aug-85 1505 RPG
C02341 00647 ∂16-Aug-85 1505 RPG Common Lisp Bill Board
C02344 00648 ∂16-Aug-85 1536 RPG Greetings
C02346 00649 ∂18-Aug-85 1159 Moon@SCRC-STONY-BROOK.ARPA with-output-to-string query
C02350 00650 ∂18-Aug-85 1519 FAHLMAN@CMU-CS-C.ARPA with-output-to-string query
C02353 00651 ∂19-Aug-85 1104 Moon@SCRC-STONY-BROOK.ARPA with-output-to-string query
C02357 00652 ∂19-Aug-85 2350 TIM@MIT-MC.ARPA Side effecting constants inside functions
C02360 00653 ∂20-Aug-85 0049 GSB@MIT-MC.ARPA Side effecting constants inside functions
C02365 00654 ∂21-Aug-85 1057 robbins@DEC-HUDSON close queries
C02367 00655 ∂25-Aug-85 0015 TIM@MIT-MC.ARPA Side effecting constants inside functions
C02371 00656 ∂26-Aug-85 0737 Hornig@SCRC-STONY-BROOK.ARPA Side effecting constants inside functions
C02374 00657 ∂30-Aug-85 1411 @MIT-MC.ARPA:cfry@MIT-OZ put me on mailing list
C02375 00658 ∂30-Aug-85 1938 IMSSS@SUMEX-AIM.ARPA Re: close queries
C02377 00659 ∂31-Aug-85 0617 MLY@MIT-MC.ARPA lexical madness
C02379 00660 ∂31-Aug-85 1450 edsel!eb@Navajo New constants needed
C02381 00661 ∂01-Sep-85 0743 FAHLMAN@CMU-CS-C.ARPA New constants needed
C02384 00662 ∂01-Sep-85 0942 greek@DEC-HUDSON Letting LET bind the same variable more than once.
C02385 00663 ∂01-Sep-85 0948 greek@DEC-HUDSON STRING-CHAR-CODE-LIMIT
C02387 00664 ∂01-Sep-85 1606 LOOSEMORE@UTAH-20.ARPA compiling multiple files
C02390 00665 ∂01-Sep-85 1944 Moon@SCRC-STONY-BROOK.ARPA STRING-CHAR-CODE-LIMIT
C02392 00666 ∂02-Sep-85 1519 Masinter.pa@Xerox.ARPA Re: lexical madness
C02394 00667 ∂02-Sep-85 1745 Masinter.pa@Xerox.ARPA Re: Side effecting constants inside functions
C02397 00668 ∂02-Sep-85 1808 Masinter.pa@Xerox.ARPA constructor function vs constructor macro
C02399 00669 ∂02-Sep-85 1829 FAHLMAN@CMU-CS-C.ARPA lexical madness
C02401 00670 ∂02-Sep-85 1855 FAHLMAN@CMU-CS-C.ARPA constructor function vs constructor macro
C02403 00671 ∂02-Sep-85 2203 EVAN@SU-CSLI.ARPA Re: Side effecting constants inside functions
C02405 00672 ∂03-Sep-85 0240 EVAN@SU-CSLI.ARPA Re: Side effecting constants inside functions
C02407 00673 ∂03-Sep-85 0623 greek@DEC-HUDSON STRING-CHAR-CODE-LIMIT = CHAR-CODE-LIMIT
C02408 00674 ∂03-Sep-85 0720 smh@mit-ems.ARPA Re: Side effecting constants inside functions
C02414 00675 ∂03-Sep-85 1024 DLW@SCRC-VALLECITO.ARPA Re: Side effecting constants inside functions
C02417 00676 ∂03-Sep-85 1039 DLW@SCRC-QUABBIN.ARPA Re: Side effecting constants inside functions
C02420 00677 ∂03-Sep-85 1207 EVAN@SU-CSLI.ARPA Re: Side effecting constants inside functions
C02422 00678 ∂03-Sep-85 1220 EVAN@SU-CSLI.ARPA Re: Side effecting constants inside functions
C02425 00679 ∂03-Sep-85 1310 REM%IMSSS.#Pup@SU-SCORE.ARPA shared structure, other restrictions on program=data
C02428 00680 ∂03-Sep-85 1619 DLW@SCRC-QUABBIN.ARPA constructor function vs constructor macro
C02430 00681 ∂03-Sep-85 1619 DLW@SCRC-QUABBIN.ARPA Re: lexical madness
C02433 00682 ∂03-Sep-85 1627 wilensky@ucblarch inconsistency in the definitions of round-off functions
C02435 00683 ∂03-Sep-85 1849 SCHUMACHER%hp-hulk.csnet@csnet-relay.arpa Re: compiling multiple files
C02437 00684 ∂03-Sep-85 2111 edsel!eb@su-navajo.arpa Modifying constants in programs
C02441 00685 ∂04-Sep-85 0301 RWK@SCRC-STONY-BROOK.ARPA Re: compiling multiple files
C02444 00686 ∂04-Sep-85 0604 REM%IMSSS.#Pup@SU-SCORE.ARPA LISP has both pure and reference data types
C02451 00687 ∂04-Sep-85 0614 REM%IMSSS.#Pup@SU-SCORE.ARPA More on reference/pure data, declaration not really needed
C02454 00688 ∂04-Sep-85 0649 BSG@SCRC-STONY-BROOK.ARPA Re: Side effecting constants inside functions
C02457 00689 ∂04-Sep-85 0804 LOOSEMORE@UTAH-20.ARPA Re: compiling multiple files
C02460 00690 ∂04-Sep-85 0834 FAHLMAN@CMU-CS-C.ARPA inconsistency in the definitions of round-off functions
C02462 00691 ∂04-Sep-85 0843 DCP@SCRC-YUKON.ARPA Re: compiling multiple files
C02466 00692 ∂04-Sep-85 1208 gls@THINK-AQUINAS.ARPA Errata for Common Lisp manual
C02474 00693 ∂04-Sep-85 1252 BROOKS%MIT-OZ@MIT-MC.ARPA Re: Errata for Common Lisp manual
C02475 00694 ∂04-Sep-85 1350 DLW@SCRC-STONY-BROOK.ARPA Re: Side effecting constants inside functions
C02478 00695 ∂04-Sep-85 1535 EVAN@SU-CSLI.ARPA GLisp for Common Lisp
C02479 00696 ∂05-Sep-85 0714 wagner@GSWD-VMS Erratum
C02480 00697 ∂05-Sep-85 1037 RAM@CMU-CS-C.ARPA Top-level forms and eval-when in the compiler
C02482 00698 ∂05-Sep-85 2141 Moon@SCRC-YUKON.ARPA close queries
C02485 00699 ∂06-Sep-85 1154 franz!jkf@Berkeley Re: close queries
C02489 00700 ∂06-Sep-85 1708 FAHLMAN@C.CS.CMU.EDU close queries
C02491 00701 ∂06-Sep-85 2212 Moon@SCRC-STONY-BROOK.ARPA Re: close queries
C02496 00702 ∂07-Sep-85 1043 greek@DEC-HUDSON Closing Synonum Streams.
C02499 00703 ∂07-Sep-85 1115 fateman%ucbdali@Berkeley comment and errata on synonyms, streams.
C02502 00704 ∂07-Sep-85 1337 franz!jkf@Berkeley longwinded reply to close queries
C02510 00705 ∂09-Sep-85 0910 DCP@SCRC-STONY-BROOK.ARPA go and return-from inside unwind-protect cleanup
C02512 00706 ∂09-Sep-85 0934 gls@THINK-AQUINAS.ARPA Closing Synonum Streams.
C02514 00707 ∂09-Sep-85 1001 gls@THINK-AQUINAS.ARPA go and return-from inside unwind-protect cleanup
C02520 00708 ∂10-Sep-85 1458 J.Dalton%edxa@ucl-cs.ARPA More errata
C02522 00709 ∂10-Sep-85 2223 TIM@MIT-MC.ARPA Top-level forms and eval-when in the compiler [and macrolet too!]
C02524 00710 ∂11-Sep-85 1133 JAR@MIT-MC.ARPA Top-level forms and eval-when in the compiler [and macrolet too!]
C02527 00711 ∂11-Sep-85 1144 FAHLMAN@C.CS.CMU.EDU Top-level forms and eval-when in the compiler [and macrolet too!]
C02529 00712 ∂11-Sep-85 1232 REM%IMSSS.#Pup@SU-SCORE.ARPA Compiling anonymous functions embedded in structure
C02532 00713 ∂11-Sep-85 1323 MMcM@SCRC-STONY-BROOK.ARPA LAMBDA expression to the SATISFIES type specifier
C02534 00714 ∂11-Sep-85 1337 gls@THINK-AQUINAS.ARPA LAMBDA expression to the SATISFIES type specifier
C02537 00715 ∂11-Sep-85 1446 @SU-SCORE.ARPA,@MIT-REAGAN.ARPA:SOLEY@MIT-MC.ARPA Compiling anonymous functions embedded in structure
C02540 00716 ∂11-Sep-85 1935 FAHLMAN@C.CS.CMU.EDU Top-level forms and eval-when in the compiler [and macrolet
C02548 00717 ∂11-Sep-85 2039 KSH@MIT-MC.ARPA
C02552 00718 ∂12-Sep-85 0439 bsg@SCRC-STONY-BROOK.ARPA Not pound-sign dot, fools!
C02555 00719 ∂12-Sep-85 0536 BSG@SCRC-STONY-BROOK.ARPA Not sharp-sign dot, fools!
C02559 ENDMK
C⊗;
∂24-Jan-85 1800 Moon@SCRC-STONY-BROOK.ARPA Make-Hash-Table
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Jan 85 18:00:07 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 165974; Thu 24-Jan-85 21:01:32-EST
Date: Thu, 24 Jan 85 21:00 EST
From: David A. Moon <Moon@SCRC-RIVERSIDE.ARPA>
Subject: Make-Hash-Table
To: Skef Wholey <Wholey@CMU-CS-C.ARPA>
cc: Common-Lisp@SU-AI.ARPA, Common-Lisp-Implementation@SU-AI.ARPA,
bug-CLCP@SCRC-STONY-BROOK.ARPA
In-Reply-To: <WHOLEY.12081735733.BABYL@CMU-CS-C.ARPA>
Message-ID: <850124210049.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 22 Jan 1985 22:56 EST
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
I propose the following clarification to the specification of how the
:rehash-threshold and :rehash-size options interact:
There are four cases:
1. :rehash-threshold is an integer and :rehash-size is an integer.
In this case, when a hash table is grown (by adding rehash-size to
the current hash table size), the rehash-threshold is scaled up by
multiplying it by the ceiling of the ratio of the new size to the
original size.
2. :rehash-threshold is an integer and :rehash-size is a float.
In this case, when a hash table is grown (by multiplying the current
hash table size by the rehash-size), the rehash-threshold is scaled
up by multiply it, too, by the rehash-size.
Don't forget to convert the result of that multiplication from a float back
to an integer!
3. :rehash-threshold is a float and :rehash-size is an integer.
In this case, when a hash table is grown (by adding rehash-size to
the current hash table size), we just leave the rehash-threshold
alone.
4. :rehash-threshold is a float and :rehash-size is a float.
To grow, just multiply the current hash table size by the rehash-size
and again leave the rehash-threshold alone.
If :rehash-threshold is a fixnum, then the hash table is grown when the number
of entries in the table exceeds the :rehash-threshold. If :rehash-threshold is
a float, then the hash table is grown when the ratio of the number of entries
in the to the size of the table exceeds the :rehash-threshold.
I think you can eliminate cases 1 and 2 by the trick of doing
(when (integerp rehash-threshold)
(setq rehash-threshold (/ (float rehash-threshold) size)))
at initialization. Now it scales automatically.
This seems to be the "obvious" interpretation of the description on pages
283-284, and this is how I intended to implement hash tables for Spice Lisp.
I believe this interpretation.
Bug-CLCP: We don't seem to implement any case other than #4. This is mentioned
in the release notes.
∂24-Jan-85 1800 Moon@SCRC-STONY-BROOK.ARPA Make-Hash-Table
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Jan 85 18:00:07 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 165974; Thu 24-Jan-85 21:01:32-EST
Date: Thu, 24 Jan 85 21:00 EST
From: David A. Moon <Moon@SCRC-RIVERSIDE.ARPA>
Subject: Make-Hash-Table
To: Skef Wholey <Wholey@CMU-CS-C.ARPA>
cc: Common-Lisp@SU-AI.ARPA, Common-Lisp-Implementation@SU-AI.ARPA,
bug-CLCP@SCRC-STONY-BROOK.ARPA
In-Reply-To: <WHOLEY.12081735733.BABYL@CMU-CS-C.ARPA>
Message-ID: <850124210049.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 22 Jan 1985 22:56 EST
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
I propose the following clarification to the specification of how the
:rehash-threshold and :rehash-size options interact:
There are four cases:
1. :rehash-threshold is an integer and :rehash-size is an integer.
In this case, when a hash table is grown (by adding rehash-size to
the current hash table size), the rehash-threshold is scaled up by
multiplying it by the ceiling of the ratio of the new size to the
original size.
2. :rehash-threshold is an integer and :rehash-size is a float.
In this case, when a hash table is grown (by multiplying the current
hash table size by the rehash-size), the rehash-threshold is scaled
up by multiply it, too, by the rehash-size.
Don't forget to convert the result of that multiplication from a float back
to an integer!
3. :rehash-threshold is a float and :rehash-size is an integer.
In this case, when a hash table is grown (by adding rehash-size to
the current hash table size), we just leave the rehash-threshold
alone.
4. :rehash-threshold is a float and :rehash-size is a float.
To grow, just multiply the current hash table size by the rehash-size
and again leave the rehash-threshold alone.
If :rehash-threshold is a fixnum, then the hash table is grown when the number
of entries in the table exceeds the :rehash-threshold. If :rehash-threshold is
a float, then the hash table is grown when the ratio of the number of entries
in the to the size of the table exceeds the :rehash-threshold.
I think you can eliminate cases 1 and 2 by the trick of doing
(when (integerp rehash-threshold)
(setq rehash-threshold (/ (float rehash-threshold) size)))
at initialization. Now it scales automatically.
This seems to be the "obvious" interpretation of the description on pages
283-284, and this is how I intended to implement hash tables for Spice Lisp.
I believe this interpretation.
Bug-CLCP: We don't seem to implement any case other than #4. This is mentioned
in the release notes.
∂25-Jan-85 0801 REM@IMSSS how to document yellow page entries, belated discussion by REM
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 85-01-25 07:57:12 PST (=GMT-8hr)
Date: 85-01-25 07:54:58 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132012160130.G0348
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:Fahlman@CMU-CS-C
CC:COMMON-LISP@SU-AI
Subject: how to document yellow page entries, belated discussion by REM
Reply-to: REM%IMSSS@SU-SCORE.ARPA
> Date: Thu, 24 Jan 1985 21:18 EST
> From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
>
> ;;; Program name: Gritch Generator
> ;;; Keywords: foo, bar, grumble, bletch
> ;;; Author: James Madison
> ;;; Description: This is an example of a long field that goes onto more
> ;;; than one line. The subsequent lines have this extra bit of
> ;;; indentation after the triple-semicolon stuff.
One disadvantage of this format, as any ;-style comments, is that when
you copy a file using the LISP reader, such as to prettyprint or to
translate to another dialect, or to convert into or out of RLISP form,
or to expand some private macros, etc., all those comments are
stripped off during READing and thus will be missing from the output
version of the program. Do you know of a LISP pseudo-reader that
somehow internalizes sections of a file like READ does except that
;-style comments are retained, somehow attached to the normal
s-expressions, so that when the file is PRINTed or PRETTYPRINTed etc.
back out using a correspondingly-modified version of the appropriate
output function the ;-style comments are put back in?
If not, I would say that *any* use of ;-style comments in an otherwise
READable&PRINTable LISP-source file is bad programming style since it
limits the kinds of processing that can effectively be done on the file.
(CC to COMMON-LISP general forum to spark debate on this controversial issue.)
∂26-Jan-85 1753 FAHLMAN@CMU-CS-C.ARPA how to document yellow page entries, belated discussion by REM
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Jan 85 17:53:13 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 26 Jan 85 20:54:38-EST
Date: Sat, 26 Jan 1985 20:54 EST
Message-ID: <FAHLMAN.12082762097.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: REM%IMSSS@SU-SCORE.ARPA
Cc: COMMON-LISP@SU-AI.ARPA
Subject: how to document yellow page entries, belated discussion by REM
In-reply-to: Msg of 85-01-25 07:54:58 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>
I totally disagree with your statement that *any* use of ;-style
comments in an otherwise readable and printable file is bad programming
style. If there is some reason you want to process or save such
comments when the file is read, it is a trivial matter to redefine the
character macro for #\; to pack the comment line into a string and
return it in some form that the reader will find unobjectionable.
So I see no reason why ;-style comments are not a good vehicle for
header information in yellow pages files. The default Common Lisp
reader discards these things, but that's what you want most of the time.
If you want a program to extract and save this stuff, building a reader
to do that is well within the capabilities of most beginning Lisp
programmers.
-- Scott
∂26-Jan-85 2003 FAHLMAN@CMU-CS-C.ARPA A proposal
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Jan 85 20:03:19 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 26 Jan 85 23:04:42-EST
Date: Sat, 26 Jan 1985 23:04 EST
Message-ID: <FAHLMAN.12082785776.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: cl-charter@SU-AI.ARPA, ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA,
squires@USC-ISI.ARPA
Subject: A proposal
So far, I've only received two replies to my charter proposal, one from
Guy Steele and one from Richard Fateman. That means either that (a) all
the rest of you agree with my proposal in all its details, (b) all of
you find it so hopelessly wrong that it's not worth commenting on, (c)
none of you give a damn about these issues, or (d) you people out in
companies only read your mail once a month. At least let me know which
of these is really the case.
Fateman favors going with no formal organization at all, in part because
he believes that the legal fees will be overwhelming if we try to start
such a thing. Does anyone have some hard data on the legal costs for
similar efforts?
To answer another of Fateman's queries, I think that Digital Press would
be quite willing to turn the copyright over to the organization, once it
is up and running, as long as they retain the exclusive rights to
publish the manual in commercial book form. They have suggested as much
in preliminary discussions, though there are a large number of details
to be worked out. We can't proceed with anything like this until there
is some entity with whom they can make the deal.
We come finally, to the central point:
Why, after all this, is (3) not so bad? Well, look at what happened
to Lisp 1.5, and the little MIT press blue&white book describing it.
Was that so bad? Did anyone ever validate a lisp 1.5 implementation?
In my opinion, it was "so bad". The lack of a usable standard
for Lisp 1.5, and some way of updating that standard as Lisp evolved
into something whose relation to Lisp 1.5 was almost unrecognizable, was
responsible for a couple of major schisms and a huge amount of duplicated
effort. The resulting chaotic situation probably set the
commercialization of AI back by 5 years or so.
Finally, Fateman argues that a separate organization would make it
inevitable that the original group of Common Lisp people would lose
control of the language as more and more companies develop a strong
commercial interest in it. That seems like a desirable evolution to me.
Who better to control the language than those who have a stake in it?
If the language becomes too stable over time, we researchers will just
have to call our wild new languages something else.
Both Fateman and Steele have expressed some uneasiness over the veto
power that I proposed for the industrial members, on the grounds that
such companies would tend to be too conservative. I think that both of
you are selling the companies short. I have not noticed any tendency of
the companies involved in this process to be more conservative than
anyone else. On a lot of issues I've been the conservative, or Gabriel
has, or Hedrick or Fateman -- academics all (at the time). Where people
from the stock-hardware companies have felt that they lacked expertise
on some issue, they have generally kept quiet. I see no reason to
believe that this would change. Of course the companies will resist any
expensive changes for which there is not a clear benefit to be gained,
but so will the rest of us -- that's what stability is all about.
Note that I am NOT proposing that any single company, or small group of
them, be given a veto. That would be disastrous. But if the technical
committee cannot persuade at least half of the companies that some change
is worthwhile, it seems to me that the change should not go through.
Note also that even a majority of the companies could not force through
a lot of changes that would ruin the existing language, unless they also
gain control of the technical committee. The pressure to come up with
subsets and compromises will evaporate after a year or two; by then,
most companies will be offering full Common Lisp implementations and
will no longer have much interest in reverting to dynamic scoping or
flushing all of the sequence functions.
The reason for including this veto provision in the first place is that,
when I try to look at this organization from the point of view of the
companies who want to invest heavily in Common Lisp, I see a need for
some protection against the technical committee (a small group of
people, after all) going crazy and changing the language beyond all
recognition, destroying my investment. To spin out just one disturbing
fantasy, some company that does not want to see Common Lisp succeed
might try to pack the association with its employees as individual
members, elect a technical committee of its own liking, and hijack the
language definition machinery. The mere existence of a veto power by
the other corporate members would eliminate this threat, I think.
For those reasons, I would oppose giving the technical committee the
final word by giving them the power to over-ride vetos. It wouldn't
bother me to require a 2/3 majority of corporate members for a veto, but
I prefer a simple majority. As a practical matter, I think that any
technical committee would be mad to shove through any change that is not
acceptable to a majority of the companies, even if they had the power to
do so.
-- Scott
∂26-Jan-85 2139 Moon@SCRC-STONY-BROOK.ARPA A proposal
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Jan 85 21:39:41 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 166927; Sun 27-Jan-85 00:42:42-EST
Date: Sun, 27 Jan 85 00:42 EST
From: David A. Moon <Moon@SCRC-RIVERSIDE.ARPA>
Subject: A proposal
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: cl-charter@SU-AI.ARPA, ohlander@USC-ISI.ARPA,
quinquevirate@SU-AI.ARPA, squires@USC-ISI.ARPA
In-Reply-To: <FAHLMAN.12082785776.BABYL@CMU-CS-C.ARPA>
Message-ID: <850127004201.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 26 Jan 1985 23:04 EST
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
So far, I've only received two replies to my charter proposal, one from
Guy Steele and one from Richard Fateman. That means either that (a) all
the rest of you agree with my proposal in all its details, (b) all of
you find it so hopelessly wrong that it's not worth commenting on, (c)
none of you give a damn about these issues, or (d) you people out in
companies only read your mail once a month. At least let me know which
of these is really the case.
(c). Note that I am not on the CL-Charter mailing list. Other people at
Symbolics are on that mailing list, perhaps they will speak up. Some of
them are extremely busy this month trying to get out a software release
on time and with an acceptable level of bugs, so maybe that explains the
delay. I am sure the "official" position of Symbolics is not (c).
The rest of your message seems reasonable to me.
∂26-Jan-85 2216 REM%IMSSS.#Pup@SU-SCORE.ARPA Character macros, erratum
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 26 Jan 85 22:16:13 PST
Received: from IMSSS by Score with Pup; Sat 26 Jan 85 22:15:36-PST
Date: 26 Jan 1985 2214-PST
From: Rem@IMSSS
Subject: Character macros, erratum
To: COMMON-LISP%SU-AI@SCORE
According to the index in the CL book, topic "characters", subtopic
"macros" is on pages 246-351 inclusive. This is obviusly a typo.
Does somebody have a collected list of errata that I could use to
fixup my copy of the book en masse to avoid bumping into already-found
errata? I think I asked this general question when I first found out
about this mailing list, but nobody knew of any such errata collection.
[Erratum of my own, which I cannot correct in NETMSG=SNDMSG:
obviusly -> obviously]
-------
∂26-Jan-85 2340 fateman%ucbdali@Berkeley Re: A proposal
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 26 Jan 85 23:40:02 PST
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.41)
id AA07748; Sat, 26 Jan 85 23:41:07 pst
Received: by ucbdali.ARPA (4.24/4.40)
id AA26395; Sat, 26 Jan 85 23:41:09 pst
Date: Sat, 26 Jan 85 23:41:09 pst
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8501270741.AA26395@ucbdali.ARPA>
To: Fahlman@CMU-CS-C.ARPA, cl-charter@SU-AI.ARPA, ohlander@USC-ISI.ARPA,
quinquevirate@SU-AI.ARPA, squires@USC-ISI.ARPA
Subject: Re: A proposal
Fateman favors going with no formal organization at all, in part because
he believes that the legal fees will be overwhelming if we try to start
such a thing. Does anyone have some hard data on the legal costs for
similar efforts?
I am sure that the costs would be higher for anything "original"
(as opposed to what has been done with Fortran, COBOL, Basic, Pascal, MUMPS).
I wonder if the extra cost would buy much.
To answer another of Fateman's queries, I think that Digital Press would
be quite willing to turn the copyright over to the organization, once it
is up and running, as long as they retain the exclusive rights to
publish the manual in commercial book form.
Whose manual? CommonLisptheLanguage is not a reference manual. Where, for
example, are the error messages? The debugger? It is an incomplete work.
I agree that there are a large number of details to be worked out, but there
are some major issues, too. To what extent does DEC own all "composite" works?
Would DEC permit a "composite" to remove sections or paragraphs ... e.g.
to change the meaning of a function .. or to use dynamic rather than
lexical scope? Or would DEC be the de facto standard setter by saying that
if you alter anything you must write the manual from scratch?
The lack of a usable standard
for Lisp 1.5, and some way of updating that standard as Lisp evolved
into something whose relation to Lisp 1.5 was almost unrecognizable, was
responsible for a couple of major schisms and a huge amount of duplicated
effort. The resulting chaotic situation probably set the
commercialization of AI back by 5 years or so.
I guess I disagree. The effort to make an Interlisp program run in a
Maclisp system, or vice versa strikes me as not so great. Few people
have wanted to use other people's "magnum opus" programs as components in
their systems. The fact that some were Interlisp and others Maclisp
is irrelevant. The smaller programs... tools like the BBN/Interlisp/CMU-Franz
structure editor or flavors .. have been moved. In spite of the biennial
Crisis-in-Lisp meetings, I am not sure anyone can point to any great
waste of human effort in retargeting. It's been mostly religion, and
all we see now is Maclisp is in the ascendancy.
Perhaps this is not the place to discuss the question, but do you have
in mind some "commercial AI program of today" that might have been out
5 years earlier? Certainly Macsyma would not have been affected by this
issue. I doubt that KEE would have been.
I think hardware has been much more critical.
The pressure to come up with
subsets and compromises will evaporate after a year or two; by then,
most companies will be offering full Common Lisp implementations and
will no longer have much interest in reverting to dynamic scoping or
flushing all of the sequence functions.
I doubt it. Do you think IBM PCs and Macintoshes will evaporate in 2 years?
To spin out just one disturbing
fantasy, some company that does not want to see Common Lisp succeed
might try to pack the association with its employees as individual
members, elect a technical committee of its own liking, and hijack the
language definition machinery.
How has this been avoided in Fortran or ... committees? Why are you assuming
we must break new ground?
I too would like to hear from the others..
∂27-Jan-85 0952 FAHLMAN@CMU-CS-C.ARPA A proposal
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Jan 85 09:52:43 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 27 Jan 85 12:53:47-EST
Date: Sun, 27 Jan 1985 12:53 EST
Message-ID: <FAHLMAN.12082936705.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: fateman%ucbdali@λBerkeley (Richard Fateman)λ
Cc: cl-charter@SU-AI.ARPA, ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA,
squires@USC-ISI.ARPA
Subject: A proposal
Richard,
I am sure that the costs would be higher for anything "original"
(as opposed to what has been done with Fortran, COBOL, Basic, Pascal, MUMPS).
I wonder if the extra cost would buy much.
Well, our situation is unique in some ways, I think, but I certainly
don't want to invent any more of this than is necessary. One reason I'm
uneasy about chairing this group is that I've carefully avoided
standardization committees and other such political groups in the past,
so I'm not very well acquainted with some of these earlier efforts. All
that I've heard about them have been a lot of horror stories. If anyone
can point to an existing model that they think is worth emulating, and
to some way of getting the details on it, I'd love to copy something
successful.
On the manual issue, the Common Lisp organization would control the
content and any additions. Digital Press has never wanted to control
the content of they manual; they have tried to faithfully follow our
request that nobody be allowed to reprint the manual with random
mutations of their own choosing. I think that Digital Press would be
satisfied with any arrangement in which, if some composite work is to be
published as a commercial book, they either do the publishing or get a
roylaty on the part of the work they now control. The problem with
licensing legitimate derivitive works has been the low bandwidth of our
interations with Digital Press, the slow pace at which Digital Press
does anything, and some confusion about who speaks for the Common Lisp
community. If the organization were to gain control of the copyright,
these problems would be greatly alleviated. In fact, that's one of the
biggest reasons why we ought to move fast on this charter business and
not let it sit for a year.
As for the "5 years earlier" issue, I wasn't terribly close to Macsyma,
but it is probably a good example of a program that would have found its
way into industry many years ago if the Lisp that it ran on was stable,
well-documented, and ran more or less compatibly on a variety of
machines. When I was at MIT, eight or so years ago, I heard many rumors
of industrial groups looking into Macsyma and other early Maclisp-based
systems and giving up when they saw what kind of shape Maclisp was in.
(Some of them probably were driven away by MIT's lawyers instead, but
that's another problem.)
I don't think that Macintoshes and IBM PC's will have disappeared in two
years, but I am quite sure that virtual-memory PC's, capable of running
a full Common Lisp with editor and compiler, will exist within that time
frame at prices comparable to today's Macintoshes and PC's. There will
be plenty of non-VM personal computers still running -- older machines
or super-cheap ones -- but there will be plenty of clean,
well-considered subsets of Common Lisp running on these machines.
Right now, most of the pressure for substantially altering Common Lisp
comes not from the small-machine people, but from those trying to turn
some already-existing Lisp into Common Lisp by bending it a little.
This is the game that I think will be over within a year or two. By
then, these people will either have succeeded in developing a legal
Common Lisp from wherever they are starting, or will have been blown
away by some from-scratch Common Lisp implementation for the same
machine.
-- Scott
∂27-Jan-85 1701 @MIT-MC:PGS@MIT-OZ definition of lexical closure
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Jan 85 17:00:58 PST
Date: Sun, 27 Jan 1985 19:57 EST
Message-ID: <PGS.12083013843.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To: common-lisp@SU-AI.ARPA
Subject: definition of lexical closure
I was talking to someone today about the Common Lisp notion of a closure, and
I noticed that the definition of a lexical closure on page 87 of the CL
manual is sort of vague and unsatisfactory. It says that a lexical closure
is the object returned by FUNCTION, that is, a function which, when invoked,
obeys the rules for lexical scoping.
The problem with this definition is that it makes it difficult to explain why
the thing referred to is called a closure. It's hard to relate the definition
even vaguely to the set-theoretic notion of a closure, because it doesn't
describe a set, so one can't explain the term as coming from the notion of
`closing over' a set of bindings.
If you say that the reason why lexical closures are functions in Common Lisp,
and not just sets of bindings, is because there is this sense of a closure
not only of the bindings in the definition environment, but of the bindings
of the formals to the actuals in the invocation of a function, you create
this other pedagogical problem, which is that the thing returned by FUNCTION
isn't a lexical closure then, because it can't include the bindings created
by function invocation, because those bindings are created afresh whenever
the function is invoked, and don't even exist when the object is returned.
It was easier to explain what a Lisp Machine Lisp closure was, because there
was an idea that a closure existed as something separate from a function. One
could do more than invoke the closure's function; there were things like
SYMEVAL-IN-CLOSURE, for example. So a closure could be explained as a set of
bindings, which is much more palatable than saying that it is a function.
Those were sets of dynamic bindings. What I would like to say to people who
ask what a lexical closure is in Common Lisp is that it is a set of lexical
bindings; that is, the set of lexical bindings in the environment in which a
function is defined. Then we could say that FUNCTION returns, not a lexical
closure, but an object that includes a lexical closure, and that the
environment in which the function text is evaluated is the union of that
lexical closure with the bindings of the formals to the actuals.
I'd like to see this definition in a future edition of the CL manual, on the
grounds that it's cleaner and therefore easier to teach. Would anyone object?
∂27-Jan-85 1705 fateman%ucbdali@Berkeley Re: A proposal
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 27 Jan 85 17:05:22 PST
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.41)
id AA18772; Sun, 27 Jan 85 17:06:22 pst
Received: by ucbdali.ARPA (4.24/4.40)
id AA00855; Sun, 27 Jan 85 17:06:25 pst
Date: Sun, 27 Jan 85 17:06:25 pst
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8501280106.AA00855@ucbdali.ARPA>
To: Fahlman@CMU-CS-C.ARPA, fateman%ucbdali%λBerkeleyλ@Berkeley
Subject: Re: A proposal
Cc: cl-charter@SU-AI.ARPA, ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA,
squires@USC-ISI.ARPA
Is it your intention to forbid a lisp manual to use the CL chapter
on packages [paying suitable royalties], if the lisp in question
neglects to adopt the string chapter? How about lexical scoping?
Is this DEC's intention too? I guess I would be happier if the manual
were put in the public domain, and the imprimateur of the CL committee
was separate.
P.S...apologies for the tangent...but...
Macsyma's distribution problems have been caused by
hardware and legal issues, not divisiveness in languages. Had Macsyma
run in Interlisp and PSL, nothing would have changed. Had anyone really
wanted either of these, they could have been done, technically speaking,
without much effort.
The VAX solved the hardware issues. The MC68000 and cheap memory
made the solution more realistic.
Few people realize that Macsyma has been run routinely FOR 2 YEARS on numerous
(different) 68000-based workstations at UCB.
MIT and Symbolics have maintained legal barriers to its distribution.
∂27-Jan-85 1727 FAHLMAN@CMU-CS-C.ARPA A proposal
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Jan 85 17:26:54 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 27 Jan 85 20:27:45-EST
Date: Sun, 27 Jan 1985 20:27 EST
Message-ID: <FAHLMAN.12083019346.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: fateman%ucbdali@λBerkeley (Richard Fateman)λ
Cc: cl-charter@SU-AI.ARPA, ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA,
squires@USC-ISI.ARPA
Subject: A proposal
In-reply-to: Msg of 27 Jan 1985 20:06-EST from fateman%ucbdali at Berkeley (Richard Fateman)
Is it your intention to forbid a lisp manual to use the CL chapter
on packages [paying suitable royalties], if the lisp in question
neglects to adopt the string chapter? How about lexical scoping?
Is this DEC's intention too? I guess I would be happier if the manual
were put in the public domain, and the imprimateur of the CL committee
was separate.
I see two issues here. First, the manual is at present the sole written
form of the Common Lisp standard, and the whole community has an
interest in preventing random mutations in that standard, or confusion
as to what the standard really is. So I believe that if anyone wants to
use parts of this manual and not other parts, this should only be
allowed if there is a firm agreement that the new version clearly label
itself as not a Common Lisp, but is a distinct dialect that happens to
use a package system identical to that in Common Lisp (or whatever).
That's very important. Putting the manual in the public domain would
allow the publication of many nearly-identical versions of the manual,
all claiming to be Common Lisp, and some of them "improved" in various
ways by irresponsible or incompetent editors.
The other issue is simply makign sure that the original author and/or
the current copyright holder is appropriately compensated if commercial
use is made of significant parts of the original work. That can be a
private matter between the parties concerned.
-- Scott
∂28-Jan-85 0511 OHLANDER@USC-ISI.ARPA Re: A proposal
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 28 Jan 85 05:11:34 PST
Date: 28 Jan 1985 08:11-EST
Sender: OHLANDER@USC-ISI.ARPA
Subject: Re: A proposal
From: OHLANDER@USC-ISI.ARPA
To: Fahlman@CMU-CS-C.ARPA
Cc: cl-charter@SU-AI.ARPA, quinquevirate@SU-AI.ARPA
Cc: squires@USC-ISI.ARPA
Message-ID: <[USC-ISI.ARPA]28-Jan-85 08:11:50.OHLANDER>
In-Reply-To: <FAHLMAN.12082785776.BABYL@CMU-CS-C.ARPA>
Scott,
I have not expressed an opinion yet, not because I am not
vitally interested, but because I have been on travel and am now
just catching up with correspondence. Personnaly, I think the
charter issue is the most vital thing that has to happen if the a
users group is going to materialize. I am overjoyed that you
have taken some steps to get issues on the table and a draft
going.
I agree with Scott in that we need some form of formal
organization. In terms of what it costs to get going, we might
be able to gain some idea of what it takes from some of the
original organizers of the AAAI.
We need a formal organization because it is essential to
"institutionalize" Common Lisp in order to make provision for its
continuance after key people disappear from the scene and also in
order to retain some kind of control over its instantiation and
continued refinement. An informal group can lose interest and
not feel committed in the long run to the health of Common Lisp.
Organizations outlive its individual members, have more stature,
and have a stronger commitment to its objectives.
The veto issue is a key one. On the one hand, we have all seen
vendors who are reluctant to make changes to a language and only
issue new releases under the strongest pressure. However, as
Scott points out the vendors will have a vested interest and tend
to act as counterbalance to academics who might want to run a
little wild. I believe the essential problem is to come up with
a mechanism that permits a balance of viewpoints to prevail. I
think I lean towards a 2/3 vote to veto recommendations of the
technical community.
Ron
∂28-Jan-85 0739 OHLANDER@USC-ISI.ARPA Re: A proposal
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 28 Jan 85 07:38:59 PST
Date: 28 Jan 1985 08:23-EST
Sender: OHLANDER@USC-ISI.ARPA
Subject: Re: A proposal
From: OHLANDER@USC-ISI.ARPA
To: Fahlman@CMU-CS-C.ARPA
Cc: cl-charter@SU-AI.ARPA, quinquevirate@SU-AI.ARPA
Cc: squires@USC-ISI.ARPA
Message-ID: <[USC-ISI.ARPA]28-Jan-85 08:23:21.OHLANDER>
In-Reply-To: <FAHLMAN.12082936705.BABYL@CMU-CS-C.ARPA>
I gorgot to mention that I have talked to Osbourne at Digital
Press and Fuller at Dec. I believe that they would be willing to
stipulate that the Common Lisp Users group would own all reights
to the Common Lisp specification. Furthermore, they have both
said that they look upon their contribution to the establishment
of Common Lisp as a public service and would be willing to
contibute some share of profits to the users group. I think we
have to get some sort of agreement in writing and am going to see
if I can get government lawyers involved.
I should also point out that Digital Press's claim to a
copywright is questionable. What do they have a copyright for?
There were a number of organizations and individuals that
contributed to the overall effort. I think they may have a valid
claim to the manual, as written, but how can they have a clear
claim for the specification. to complicate the problem, how do
you diambiguate the two?
I believe that we can reach a reasonable written agreement after
we (or in conjunction with) getting a users group established.
By the way, this is another reason for formal status of the users
group. We have to get a written agreement because players will
change over the years.
Ron
∂29-Jan-85 0335 @MIT-MC:PGS@MIT-OZ definition of lexical closure
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 29 Jan 85 03:35:31 PST
Date: Tue, 29 Jan 1985 06:34 EST
Message-ID: <PGS.12083391933.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To: common-lisp@SU-AI.ARPA
Subject: definition of lexical closure
In-reply-to: Msg of 27 Jan 1985 19:57-EST from PGS
Date: Sunday, 27 January 1985 19:57-EST
From: PGS
To: common-lisp at SU-AI.ARPA
Re: definition of lexical closure
I was talking to someone today about the Common Lisp notion of a closure,
and I noticed that the definition of a lexical closure on page 87 of the
CL manual is sort of vague and unsatisfactory. It says that a lexical
closure is the object returned by FUNCTION, that is, a function which,
when invoked, obeys the rules for lexical scoping.
The problem with this definition is that it makes it difficult to explain
why the thing referred to is called a closure. It's hard to relate the
definition even vaguely to the set-theoretic notion of a closure, because
it doesn't describe a set, so one can't explain the term as coming from
the notion of `closing over' a set of bindings...
Oops, I take it all back. I dug out my copy of Kleene and found that I
really wanted the predicate calculus notion of closure, not the set-theoretic
notion of closure.
∂29-Jan-85 1328 GRISS%hp-hulk.csnet@csnet-relay.arpa Re: how to document yellow page entries, belated discussion by REM
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 29 Jan 85 13:28:02 PST
Received: from hplabs by csnet-relay.csnet id ah07582; 29 Jan 85 16:13 EST
Received: by HP-VENUS id AA16614; Mon, 28 Jan 85 07:15:34 pst
Message-Id: <8501281515.AA16614@HP-VENUS>
Date: Sun 27 Jan 85 19:29:41-PST
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Re: how to document yellow page entries, belated discussion by REM
To: Fahlman, REM%IMSSS@su-score.ARPA
Cc: COMMON-LISP@su-ai.ARPA, GRISS@hplabs.CSNET
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C@HP-VENUS>" of Sat 26 Jan 85 23:26:30-PST
Source-Info: From (or Sender) name not authenticated.
I agree with Scott. We use (as Bob Kessler pointed out) a comment convention.
Most of the time its ignored, but certain programs extract the stuff
as desired.
M
-------
∂03-Feb-85 0833 RAM@CMU-CS-C.ARPA Defstruct copiers and included structures
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Feb 85 08:33:39 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Sun 3 Feb 85 11:35:09-EST
Date: Sun, 3 Feb 1985 11:35 EST
Message-ID: <RAM.12084757395.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Defstruct copiers and included structures
Query: Does a copier for a structure correctly copy all structures
which include that structure?
I would argue that it should, both on esthetic and practical
grounds. Since the including structure is a subtype of the included
structure, it should inherit all operations on that structure. It
would also be useful to be able count on this behavior. It turns out
that our implementation already does this, since it uses the same
copier function for all structures.
Rob
∂04-Feb-85 1248 Moon@SCRC-STONY-BROOK.ARPA FLET and the INLINE declaration
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Feb 85 12:48:07 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 171683; Mon 4-Feb-85 15:44:04-EST
Date: Mon, 4 Feb 85 15:41 EST
From: David A. Moon <Moon@SCRC-QUABBIN.ARPA>
Subject: FLET and the INLINE declaration
To: Common-Lisp@SU-AI.ARPA
Message-ID: <850204154157.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 4 Feb 85 14:20 EST
From: Charles Hornig <Hornig@SCRC-STONY-BROOK>
....This is a good idea except for one problem: where do you put the
declaration? FLET and LABELS do not allow you to put declarations
before their bodies. Perhaps this is a language bug.
(flet ((plus1 (x) (1+ x)))
(declare (inline plus1)) ;; This declare is illegal in the CLM
(list (plus1 1) (plus1 2)))
You have to say
(flet ((plus1 (x) (1+ x)))
(locally (declare (inline plus1))
(list (plus1 1) (plus1 2))))
I think this is a language bug and declarations, other than declarations
of variable bindings, should have been allowed at this position in FLET,
LABELS, and MACROLET. Does anyone else have an opinion?
∂06-Feb-85 0950 brown@DEC-HUDSON Clearly non-controversial
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 6 Feb 85 09:49:38 PST
Date: Wed, 06 Feb 85 12:52:15 EST
From: brown@DEC-HUDSON
Subject: Clearly non-controversial
To: common-lisp@su-ai
Here are several clearly non-controversial functions which I think
should be considered for inclusion in the language.
USER-NAME [function]
A string is returned that identifies the current user of the
Common Lisp system. If a reasonable name cannot be determined,
NIL is returned (or an empty-string?).
(It has been suggested that this should be called something like
USER-INFORMATION and take a lot of keyword arguments.)
DELETE-SETF-METHOD access-fn [function]
Removes the update form associated with the symbol access-fn.
The access function can no longer be used as generalized
variable.
HASH-TABLE-REHASH-SIZE hash-table [function]
HASH-TABLE-REHASH-TRESHOLD hash-table [function]
HASH-TABLE-SIZE hash-table [function]
HASH-TABLE-TEST hash-table [function]
These functions return the values that were specified when
the hash-table was created.
DELETE-PACKAGE package [function]
Uninterns all the symbols interned in package, deletes the package,
and unuses all packages it uses. An error is signaled if the
package is used by any other package.
UNCOMPILE symbol [function]
Restores the interpreted function definition of a symbol if
the symbol's function definition was compiled by the COMPILE
function.
COMPILEDP symbol [function]
Returns NIL if the symbol does not have a compiled function
definition. Returns T if the symbol has a compiled function
definition which was not compiled by the COMPILE function;
for example, loaded from a compiled file. Returns the
interpreted function definition if the function was compiled
by the COMPILE function.
(This list used to contain TERMINALP which returned T if its
argument (string, pathname, etc.) was an "interactive terminal".
I think this function would be useful, but decided I was unable
to define what a terminal is, so removed it.)
-Gary Brown
∂06-Feb-85 1847 RAM@CMU-CS-C.ARPA of course you don't copy everything that includes that structure!!
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 Feb 85 18:46:50 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 6 Feb 85 21:48:04-EST
Date: Wed, 6 Feb 1985 21:47 EST
Message-ID: <RAM.12085655396.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: REM@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA
Subject: of course you don't copy everything that includes that structure!!
In-reply-to: Msg of 1985 Feb 06 17:41:06 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>
Date: 1985 February 06 17:41:06 PST (=GMT-8hr)
From: Robert Elton Maas <REM at IMSSS.SU.EDU>
To: RAM at CMU-CS-C
Re: of course you don't copy everything that includes that structure!!
> Query: Does a copier for a structure correctly copy all structures
> which include that structure?
ABSOLUTELY NOT!!!!
It's possible you had a typographic error there and said the exact
opposite of what you meant, but I'll assume no typo and answer exactly
what you said.
I think that you totally spaced what I was talking about, which was
structures and copiers as created by defstruct, with include meaning
defstruct inclusion. Looking back at my message, I noticed that I
only mentioned Defstruct in the subject...
I have had some second-thoughts thought about the issue some since I
sent the message, but I still don't think that the answer is blatently
obvious.
The thing that I realized is that if the canonical implementation of
defstruct copiers is the one that we have chosen, in which there is
basically one generic defstruct copier function that copies all types
of structures, then it is kind of silly to have distinct named copier
functions for each structure type, since there could just as easily be
one Copy-Structure function.
Presumably the rationale behind having distinct copier functions is
that they could be more efficient, since they could be specialized for
the particular structure that they copy. The problem is that any
likely scheme for significantly specializing the copier function will
probably not have the property that subtypes (by inclusion) of that
structure are correctly copied.
Rob
∂07-Feb-85 2224 WHOLEY@CMU-CS-C.ARPA Clearly non-controversial
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 Feb 85 22:24:46 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Fri 8 Feb 85 01:26:21-EST
Date: Fri, 8 Feb 1985 01:26 EST
Message-ID: <WHOLEY.12085957297.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Common-Lisp@SU-AI.ARPA
Subject: Clearly non-controversial
From: brown at DEC-HUDSON
Re: Clearly non-controversial
DELETE-SETF-METHOD access-fn [function]
Removes the update form associated with the symbol access-fn.
The access function can no longer be used as generalized
variable.
How about UN-DEFTYPE and UN-DEFSTRUCT and UN-DEFCONSTANT and so on? All of
these would be useful (for the same reason as DELETE-SETF-METHOD is useful --
one is really screwed if there's no way to undo a wrong one). Coming up with a
list of all such things is a non-trivial task, and including one without all
others could be silly. On the other hand, adding a dozen undo functions to the
language, however simple, might stir up some controversy. I don't know the
right way to go here. Perhaps implementors might include information on how to
undo these things in their red pages. Undoing functions could conceivably be
treated as "user interface", since they aren't likely to appear in programs.
HASH-TABLE-REHASH-SIZE hash-table [function]
HASH-TABLE-REHASH-TRESHOLD hash-table [function]
HASH-TABLE-SIZE hash-table [function]
HASH-TABLE-TEST hash-table [function]
These functions return the values that were specified when
the hash-table was created.
When it was created? How about the current (possibly after rehashing) values?
Was your above description a thinko? Could the rehash parameters be set with
SETF? [Rambling ideas: That could be useful for growing hash tables in some
non-linear, non-exponential fashion. Maybe :REHASH-SIZE could also be a
function, in which case it takes an integer (the old size) and returns an
integer (the new size). :REHASH-THRESHOLD could likewise be a two-arg
predicate. This would let you rehash hash tables every Tuesday, for example.]
DELETE-PACKAGE package [function]
Uninterns all the symbols interned in package, deletes the package,
and unuses all packages it uses. An error is signaled if the
package is used by any other package.
Yes, that's definitely a good thing to have. Hint for programmers living
without this: use Rename-Package to get rid of the bogus package.
(This list used to contain TERMINALP which returned T if its
argument (string, pathname, etc.) was an "interactive terminal".
I think this function would be useful, but decided I was unable
to define what a terminal is, so removed it.)
I don't think all implementations could accurately answer the "is this stream
backed by a user" question. I guess a second value indicating whether or not
the answer was determined for sure would have to be returned. What would you
use such a thing for? I can only think of things that aren't really good
things for supposedly portable programs to do. In line with the other
stream type predicate functions (e.g. Input-Stream-P), perhaps the name could
be Interactive-Stream-P?
--Skef
∂07-Feb-85 2330 WHOLEY@CMU-CS-C.ARPA Clearly non-controversial
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 Feb 85 22:24:46 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Fri 8 Feb 85 01:26:21-EST
Date: Fri, 8 Feb 1985 01:26 EST
Message-ID: <WHOLEY.12085957297.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Common-Lisp@SU-AI.ARPA
Subject: Clearly non-controversial
From: brown at DEC-HUDSON
Re: Clearly non-controversial
DELETE-SETF-METHOD access-fn [function]
Removes the update form associated with the symbol access-fn.
The access function can no longer be used as generalized
variable.
How about UN-DEFTYPE and UN-DEFSTRUCT and UN-DEFCONSTANT and so on? All of
these would be useful (for the same reason as DELETE-SETF-METHOD is useful --
one is really screwed if there's no way to undo a wrong one). Coming up with a
list of all such things is a non-trivial task, and including one without all
others could be silly. On the other hand, adding a dozen undo functions to the
language, however simple, might stir up some controversy. I don't know the
right way to go here. Perhaps implementors might include information on how to
undo these things in their red pages. Undoing functions could conceivably be
treated as "user interface", since they aren't likely to appear in programs.
HASH-TABLE-REHASH-SIZE hash-table [function]
HASH-TABLE-REHASH-TRESHOLD hash-table [function]
HASH-TABLE-SIZE hash-table [function]
HASH-TABLE-TEST hash-table [function]
These functions return the values that were specified when
the hash-table was created.
When it was created? How about the current (possibly after rehashing) values?
Was your above description a thinko? Could the rehash parameters be set with
SETF? [Rambling ideas: That could be useful for growing hash tables in some
non-linear, non-exponential fashion. Maybe :REHASH-SIZE could also be a
function, in which case it takes an integer (the old size) and returns an
integer (the new size). :REHASH-THRESHOLD could likewise be a two-arg
predicate. This would let you rehash hash tables every Tuesday, for example.]
DELETE-PACKAGE package [function]
Uninterns all the symbols interned in package, deletes the package,
and unuses all packages it uses. An error is signaled if the
package is used by any other package.
Yes, that's definitely a good thing to have. Hint for programmers living
without this: use Rename-Package to get rid of the bogus package.
(This list used to contain TERMINALP which returned T if its
argument (string, pathname, etc.) was an "interactive terminal".
I think this function would be useful, but decided I was unable
to define what a terminal is, so removed it.)
I don't think all implementations could accurately answer the "is this stream
backed by a user" question. I guess a second value indicating whether or not
the answer was determined for sure would have to be returned. What would you
use such a thing for? I can only think of things that aren't really good
things for supposedly portable programs to do. In line with the other
stream type predicate functions (e.g. Input-Stream-P), perhaps the name could
be Interactive-Stream-P?
--Skef
∂12-Feb-85 1931 JLW Your non-controversial suggestions for function names
To: brown@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
Eric Benson and I quite independently came up with the need for
DELETE-PACKAGE last week; oddly enough, we even chose the same
name!
The 3600 documentation has 'pkg-kill' to de-register a package
(its name and all nicknames) and to flush the respective 'use'
lists; but we rather agree that DELETE-PACKAGE ought also to
make a pass over the atoms in the package to insure that any
who are interned with that packge as 'home' have their symbol-package
slot smashed [i.e., at least a subset of what unintern would do].
-- JonL --
∂14-Feb-85 1140 KMP@SCRC-STONY-BROOK.ARPA Not clearly non-controversial
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 Feb 85 11:39:40 PST
Received: from SCRC-MISSISSIPPI by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 178344; Thu 14-Feb-85 14:41:19-EST
Date: Thu, 14 Feb 85 14:41 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Not clearly non-controversial
To: brown@DEC-HUDSON.ARPA, COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 6 Feb 85 12:52-EST from brown at DEC-HUDSON
Message-ID: <850214144132.2.KMP@MISSISSIPPI.SCRC.Symbolics.COM>
Date: Wed, 06 Feb 85 12:52:15 EST
From: brown@DEC-HUDSON
Re: Clearly non-controversial
USER-NAME [function]
A string is returned that identifies the current user of the
Common Lisp system. If a reasonable name cannot be determined,
NIL is returned (or an empty-string?).
(It has been suggested that this should be called something like
USER-INFORMATION and take a lot of keyword arguments.)
Not just user information, but system information. eg, on the LispM it
means little (even in Common Lisp) to know the guy's name is "Joe" unless
you know what machine or site that name is relative to. At the least,
you'd need a way of getting the machine name, too. The USER-INFORMATION
thing sounds a little more plausible, but I'd prefer to see a specific
suggestion before saying go ahead.
DELETE-SETF-METHOD access-fn [function]
Removes the update form associated with the symbol access-fn.
The access function can no longer be used as generalized
variable.
I dislike the use of the morpheme "DELETE-" in this context. The Lisp
Machine uses "UN" tacked onto the defining form name, which is easy
to remember and doesn't feel like it wants a second argument of a list
to delete the thing from. Perhaps we should have a lot of UNthings.
Perhaps we should have a special form UNDO which works like SETF
but undoes things. eg, (UNDO (DEFINE-SETF-METHOD ...)) would undo a
SETF method. (UNDO (DEFUN FOO (X) ...)) would undo a DEFUN. We'd have
to define clearly the effect of:
(DEFUN F (X) X) (DEFUN F (X) (1+ X)) (UNDO (DEFUN F (X) (1+ X)))
If it wasn't to make F be an identity function again, then UNDO might
be a slightly misleading name. Anyway, I'd rather address this general
problem than add a ton of special case DELETE-mumble or UNmumble
functions.
COMPILEDP symbol [function]
Returns NIL if the symbol does not have a compiled function
definition. Returns T if the symbol has a compiled function
definition which was not compiled by the COMPILE function;
for example, loaded from a compiled file. Returns the
interpreted function definition if the function was compiled
by the COMPILE function.
What about
(DEFUN FOO (X) X)
(COMPILE 'FOO)
(DEFUN F ()
(FLET ((FOO (Y) (1+ Y)))
(COMPILEDP 'FOO)))
I would feel better if any COMPILEDP thing took an argument of
an object and told you if it were compiled. So you could write
(COMPILEDP #'symbol) instead.
Personally, I wish COMPILE had been defined to just return its result
rather than to also install it because it propagates the same kind of
confusion. But I guess it's a little late to worry about that now.
-kmp
∂18-Feb-85 1028 HEDRICK@RUTGERS.ARPA doc strings
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 18 Feb 85 10:28:36 PST
Date: 18 Feb 85 13:30:14 EST
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: doc strings
To: common-lisp@SU-AI.ARPA
Does anybody happen to have a set of documentation strings for
Common Lisp? The Spice Lisp code that we are using does have it,
but for various reasons it would be mildly helpful for us to have
a separate file that has all the doc strings.
-------
∂20-Feb-85 0216 rwg@RUSSIAN.SPA.Symbolics.COM gcd of rationals--flame added in proof
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Feb 85 02:16:20 PST
Received: from SPA-RUSSIAN by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 181670; Wed 20-Feb-85 04:52:21-EST
Received: from SPA-LOS-TRANCOS by SPA-RUSSIAN via CHAOS with CHAOS-MAIL id 102914; Wed 20-Feb-85 01:50:12-PST
Date: Wed, 20 Feb 85 01:50 PST
From: Bill Gosper <rwg@RUSSIAN.SPA.Symbolics.COM>
Subject: gcd of rationals--flame added in proof
To: ALAN@SCRC-STONY-BROOK.ARPA, fateman%ucbdali@UCB-VAX.ARPA
cc: rem@MIT-MC.ARPA, numerics@SCRC-STONY-BROOK.ARPA,
common-lisp@SU-AI.ARPA
In-Reply-To: <850129023720.8.RWG@RUSSIAN.SPA.Symbolics.COM>
Message-ID: <850220015044.3.RWG@LOS-TRANCOS.SPA.Symbolics.COM>
Date: Tue, 29 Jan 85 02:37 PST
From: Bill Gosper <rwg@RUSSIAN.SPA.Symbolics.COM>
Date: Saturday, 19 January 1985 01:03-EST
From: Alan Bawden <ALAN at SCRC-TENEX>
Date: Friday, 28 December 1984, 01:28-PST
From: Bill Gosper <rwg at SPA-NIMBUS>
Date: Wednesday, 19 December 1984, 23:45-EST
From: David C. Plummer in disguise <DCP at SCRC-QUABBIN>
[(GCD 1\4 1\3) errs.]
. . .
BTW, the correct answer is 1\12.
Not as far as ZL is concerned. Nor CL for that matter.
Ouch! They must have been jet-lagged at those CL meetings. As
Schroeppel pointed out several millenia back,
(GCD A\B C\D) = (GCD A C)/(LCM B D),
assuming args are in lowest terms. MACSYMA has long known this.
You know Gosper, I had always assumed that people who proposed to extend
GCD to the rationals were just confused about just what GCD really was, so
I was quite surprised to hear that this was an idea endorsed by Schroeppel.
So I thought about it for a while...
In what sense must the GCD of 1/3 and 1/4 be 1/12? Suppose I pick some
subring of Q that contains both 1/3 and 1/4 and I look at the ideal
generated by 1/3 and 1/4. Certainly that ideal is the same as the ideal
generated by 1/12, and in general the formula you give above will always
yeild such a generator, but there are many other elements in the ring that
generate that ideal. In fact, since 1/12 is a unit in any subring of Q,
that ideal must be generated by 1, so why not say GCD(1/3,1/4)=1? What is
the additional constraint you impose that requires 1/12?
Well, suppose that instead of thinking about GCD as defined in terms of
generators of ideals in subrings of Q, we think about GCD as defined in
terms of generators of Z-modules contained in Q. In that case, the formula
above gives the unique (modulo sign) generator of the module generated by
the arguments to GCD. But that seems somewhat arbitrary; suppose I was
working with some ring other than Z, call it A, and I wanted to play with
A-modules contained in Q? No problem! Although the formula can't always
give you a unique generator, it will give you -one- of the generators,
which is certainly the best you can ask for.
Summary: I'm convinced. This really is the right way to extend GCD to the
rational numbers if you are going to do it at all. (Since my suggestions
that GCD, NUMERATOR and DENOMINATOR be extended in the -only- possible way to
the complex integers were ignored, I have little hope that Common Lisp will
adopt the idea, however.)
But the absoLULU is further down page 202 of the CL book:
"Mathematically, (lcm) should return infinity." This is so wildly
absurd that I can't even guess the fallacy that led to it. It should
simply be 1.
It is clearly a result of taking the identity
(LCM ...) = (/ (ABS (* ...)) (GCD ...))
too seriously.
Hell, that's only valid for exactly TWO arguments!
(+ A B) is (+ (MAX A B) (MIN A B)), but
(+ A B C) isn't (+ (MAX A B C) (MIN A B C)) and
(+ A) isn't (+ (MAX A) (MIN A)) !
From: fateman@ucbdali (Richard Fateman)
To: rwg@NIMBUS.SPA.Symbolics
Subject: Re: Irrational GCD
The notion of a GCD over fractions is probably not such a great thing to
put in as a primitive in a programming language. I guess it shows how advanced
Common Lisp is.. The usual kind of programming language has
trouble with REMAINDER.
It was a real pain to get straight in macsyma, as I recall. If you worry
about unique factorization domains, I believe fields (e.g. rational numbers)
don't qualify for the GCD operation. Which means you can probably extend
the operation any way you please so long as it coincides on the integers...
e.g. gcd (a\b,c\d) == if b=d=1 then gcd(a,c) else 1.
Barf, what is all this prissy pedantry? Groups, modules, rings, ufds, patent-
office algebra. Barf!
GCD once stood for Greatest Common Divisor, an English Phrase. What is the
greatest rational that produces and integer when you divide it into 1/3 and
1/4? Answer: 1/12.
Another view. Extend unique prime factorization to rationals. Then you got
p1↑a1 p2↑a2 . . . just like with integers, except now the ai can be
negative. GCD is still prod pi↑min(ai of each arg), and LCM is still max.
Even (DEFUN EGCD (A B) (IF (ZEROP B) (ABS A) (EGCD B (\ A B)))) does the right
thing with rationals!
Then you can (DEFUN ELCM (&REST NUMS) (CL:// (APPLY #'EGCD (MAPCAR #'CL:// NUMS)))),
i.e., reciprocate the GCD of the reciprocals.
(Like MIN is negative of MAX of negatives.)
Why isn't there a CL destructive MAP on sequences??
∂21-Feb-85 1334 godot!gls@AQUINAS gcd of rationals--flame added in proof
Received: from CCA-UNIX.ARPA by SU-AI.ARPA with TCP; 21 Feb 85 13:33:40 PST
Received: by cca-unix.ARPA (4.12/4.7)
id AA10420; Thu, 21 Feb 85 16:29:22 est
Message-Id: <8502212129.AA10420@cca-unix.ARPA>
Received: by godot with CHAOS id AA23697; Thu, 21 Feb 85 16:23:58 est
Date: Thursday, 21 February 1985, 16:25-EST
From: Guy Steele <godot!gls@AQUINAS>
Subject: gcd of rationals--flame added in proof
To: rwg%RUSSIAN.SPA.Symbolics.COM@GODOT, ALAN%SCRC-STONY-BROOK.ARPA@GODOT,
fateman%ucbdali%UCB-VAX.ARPA@GODOT
Cc: rem%MIT-MC.ARPA@GODOT, numerics%SCRC-STONY-BROOK.ARPA@GODOT,
common-lisp%SU-AI.ARPA@GODOT, gls@AQUINAS
In-Reply-To: <850220015044.3.RWG@LOS-TRANCOS.SPA.Symbolics.COM>
The claim in the manual that (lcm) should be infinity is outright
wrong, as REM has already pointed out to me. Probably I was indeed
misled by the formula (/ (* x y) (gcd x y)); I cannot remember.
However, the statement is certainly my fault. I'm sorry. Maybe
in the next version of Common Lisp we can safely define (lcm) => 1,
as it will be a compatible extension.
∂26-Feb-85 0909 hpfclp!paul%hplabs.csnet@csnet-relay.arpa truncate/round/floor/ceiling functions
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 26 Feb 85 09:09:15 PST
Received: from hplabs by csnet-relay.csnet id au20234; 26 Feb 85 11:52 EST
Date: Mon, 25 Feb 85 13:25:26 pst
From: hpfclp!paul%hplabs.csnet@csnet-relay.arpa
MMDF-Warning: Parse error in preceding line at CSNET-RELAY.ARPA
Received: by HP-VENUS id AA02146; Mon, 25 Feb 85 13:25:26 pst
Message-Id: <8502252125.AA02146@HP-VENUS>
To: hplabs!common-lisp@su-ai.ARPA
Subject: truncate/round/floor/ceiling functions
Source-Info: From (or Sender) name not authenticated.
I think that I may have found an inconsistent definition for the
functions floor/round/ceiling and trucate.
This inconsistency occurs when there are 2 arguments. For example, let
us look at `(truncate 10.0 4.0)'.
1). We see that (truncate 10.0 4.0) is defined to be equivalent to
(truncate (/ 10.0 4.0)) = (truncate 2.5), which yields (2 0.5).
2.) However, applying the sentence (from pg 216 in the Aluminum Edition)
"If any of these functions is given 2 arguments x and y and
produces results q and r, then q*y + r = x."
yields, for x=10.0 and y= 4.0, q=2 and r=2.0, or a result of
(2.0 2.0).
We then have 2 different results for `truncate 10.0 4.0', depending upon
whether one does the division or not.
How is this resolved? Any clarifications would be appreciated.
Paul Beiser
Hewlett-Packard
Ft. Collins, Colorado
uucp: ...{ihnp4,hplabs}!hpfcla!paul
arpa: "hpfclp!paul%hplabs.csnet"@csnet-relay
∂26-Feb-85 1648 RAM@CMU-CS-C.ARPA truncate/round/floor/ceiling functions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Feb 85 16:48:49 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Tue 26 Feb 85 19:50:19-EST
Date: Tue, 26 Feb 1985 19:50 EST
Message-ID: <RAM.12090876859.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: hpfclp!paul%hplabs.csnet@CSNET-RELAY.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: truncate/round/floor/ceiling functions
In-reply-to: Msg of 25 Feb 1985 16:25-EST from hpfclp!paul%hplabs.csnet at csnet-relay.arpa
I had already pointed this out in a previous message on the
mailing list. The correct interpretation is that the second value is
always the remainder. The description of the meaning of the second
argument is only correct if one disregards the second value.
Rob
∂04-Mar-85 0934 RAM@CMU-CS-C.ARPA do-xxx-symbols
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Mar 85 09:34:29 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 4 Mar 85 12:33:31-EST
Date: Mon, 4 Mar 1985 12:33 EST
Message-ID: <RAM.12092370210.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
cc: common-lisp@SU-AI.ARPA
Subject: do-xxx-symbols
In-reply-to: Msg of 3 Mar 1985 21:43-EST from Charles Hedrick <HEDRICK at RUTGERS.ARPA>
Date: Sunday, 3 March 1985 21:43-EST
From: Charles Hedrick <HEDRICK at RUTGERS.ARPA>
To: ram
Re: do-xxx-symbols
The definition of DO-SYMBOLS says that it iterates over all symbols
accessible in the specified package, and that it does each once. The
term "accessible in" is ambiguous. The code I have from Spice simply
iterates over the externals and internals of that package. One could
also interpret that as including packages used by the specified package.
In that case, some interesting code would be needed to prevent a given
symbol from being used more than once, since if IMPORT was done, a
symbol could appear in several packages. Does Spice still make the
interpretation that DO-SYMBOLS looks only at the package specified?
Similarly, APROPOS talks about symbols "available in" a given package.
The wording talks about inheritance paths, so the implication seems
fairly clear that APROPOS does look at used packages.
Even after staring at the manual, I was unable to determine what the
intent was. It is unfortunate that after spending N pages developing
the theory and terminology, the actual function description blows it.
The two possibilities are to iterate over all symbols available in the
package, or only over those present in the package.
If Do-Symbols is supposed to iterate over all symbols available in the
package, then it is clearly impractical to guarantee that each symbol
is only done once, so there probably should be a caveat similar to
that for Do-All-Symbols in the Do-Symbols description. I think that
with some imagination, one could read the statement that each symbol
is done once to mean that each symbol is done at least once.
There is another problem with this interpretation, though. Before you
can iterate over any symbol for a used package, you must check to see
if the symbol is shadowed in the inheriting package. This could cause
a substantial performance penalty in Do-Symbols, since it would be
forced to do a hashtable lookup for each inherited symbol iterated
over. This means that doing an apropos in any package using the lisp
package would require doing 1000 hashtable lookups.
On the other hand, the word accessible could be replaced with
present, and everyone would be happy. Apropos would have to be
changed to do a Do-External-Symbols on each used package, and would
ignore details such as shadowed symbols.
Rob
∂04-Mar-85 1048 FAHLMAN@CMU-CS-C.ARPA do-xxx-symbols
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Mar 85 10:47:57 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 4 Mar 85 13:46:53-EST
Date: Mon, 4 Mar 1985 13:46 EST
Message-ID: <FAHLMAN.12092383554.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Cc: common-lisp@SU-AI.ARPA, Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: do-xxx-symbols
In-reply-to: Msg of 4 Mar 1985 12:33-EST from Rob MacLachlan <RAM>
I don't think that the term "accessible in" is ambiguous, given the
definition on page 172. Where is the ambiguity? So DO-SYMBOLS wants to
iterate over all of the internal and external symbols directly present
in the current package, and also those symbols that are present because
they are external in the packages used by the specified package.
I don't think we need to worry about eliminating duplicates that result
from explicit calls to IMPORT. That would entail a lot of extra
bookkeeping and would usually not be important. The business about
shadowing is a bit more complex. Technically, a symbol shadowed in
package P is not accessible in P, but again a lot of bookkeeping would
be required to eliminate these. Unless someone has a clever idea for
how to do this efficiently, we should probably revise the description of
DO-SYMBOLS to allow it to ignore this problem. In the reare case where
a user really cares, he can check for shadowed symbols himself. In any
event, the manual should be clarified on these two points.
In the description of APROPOS, the term "available in" is supposed to be
"accessible in", so the rules for DO-SYMBOLS should apply if the package
is specified, and DO-ALL-SYMBOLS if all packages are to be searched.
By the way, several groups have decided that the default for no package
specified is bogus, and that if no package is specified the user
probably should be given all symbols ACCESSIBLE IN the current package.
An argument of T could mean that you really do want to see ALL the
symbols, including internal compiler symbols, etc. Opinions?
-- Scott
∂04-Mar-85 1606 HEDRICK@RUTGERS.ARPA Re: do-xxx-symbols
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 4 Mar 85 16:06:25 PST
Date: 4 Mar 85 19:05:43 EST
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: do-xxx-symbols
To: RAM@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from "Rob MacLachlan <RAM@CMU-CS-C.ARPA>" of 4 Mar 85 12:33:00 EST
My current implementation is the following:
DO-ALL-SYMBOLS - all symbols in all packages
DO-MOST-SYMBOLS - all symbols in all packages except not internals in
LISP or COMPILER (which I claim the user is not interested in
seeing in many cases)
DO-SYMBOLS - all symbols in the package mentioned
DO-ACCESSIBLE-SYMBOLS - all symbols in the package, and all externals
in used packages. No attempt to remove shadowed symbols.
APROPOS
if package is omitted or NIL: DO-MOST-SYMBOLS
if package is T: DO-ALL-SYMBOLS
otherwise: DO-ACCESSIBLE-SYMBOLS
-------
∂04-Mar-85 1851 HEDRICK@RUTGERS.ARPA Re: do-xxx-symbols
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 4 Mar 85 18:50:55 PST
Date: 4 Mar 85 21:50:06 EST
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: do-xxx-symbols
To: Fahlman@CMU-CS-C.ARPA
cc: RAM@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>" of 4 Mar 85 13:46:00 EST
There are at least four reasons why the description of DO-SYMBOLS does
not appear to include symbols in used packages:
1) "do-symbols provides straightforward iteration over the symbols
of a package". Searching all the used packages is not straightforward
iteration over the package.
2) There is an implication that UNINTERN can be called to remove symbols
from the package. UNINTERN'ing a symbol in a used package does not
exactly remove it from the package under discussion.
3) It is said that every symbol is processed once. In DO-ALL-SYMBOLS
there is an explicit warning that symbols may occur more than once. The
implication is that this is not true for DO-SYMBOLS. If DO-SYMBOLS
was supposed to look at used packages, then the same warning would
apply to it.
4) DO-EXTERNAL-SYMBOLS says that it is like DO-SYMBOLS, but only
the external symbols of the specified package are used. The wording
of DO-EXTERNAL-SYMBOLS seems to imply even more clearly that only
the specified package is scanned, not any used packages. It also seems
to imply that DO-SYMBOLS does the same thing, but for both internal and
external symbols.
Can we get an authoritative statement about what is covered by
DO-SYMBOLS and DO-EXTERNAL-SYMBOLS, and about whether duplicates and
shadowed symbols should be removed? I think this question is
separate from the APROPOS question. APROPOS with no argument is
documented as using DO-ALL-SYMBOLS. But with an argument it is not
said to use DO-SYMBOLS. So it would be perfectly acceptable to
say that DO-SYMBOLS looks only at the symbols in a particular
package, whereas APROPOS following the used chain. (Indeed that is
what I have done for the moment.)
-------
∂04-Mar-85 2026 FAHLMAN@CMU-CS-C.ARPA do-xxx-symbols
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Mar 85 20:25:46 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 4 Mar 85 23:24:38-EST
Date: Mon, 4 Mar 1985 23:24 EST
Message-ID: <FAHLMAN.12092488741.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: do-xxx-symbols
In-reply-to: Msg of 4 Mar 1985 21:50-EST from Charles Hedrick <HEDRICK at RUTGERS.ARPA>
Can we get an authoritative statement about what is covered by
DO-SYMBOLS and DO-EXTERNAL-SYMBOLS, and about whether duplicates and
shadowed symbols should be removed?
Well, I think that the machinery for issuing authoritative statements is
pretty rusty right now. I hope that we will soon have some sort of duly
constituted authority, but right now all we have is the ad hoc executive
committee of which I am the ad hoc chairman.
Hedrick's note points out that the description in the manual is
ambiguous at best. OK. I wrote most of that (with input from Moon and
Steele, among others) and I'm sure that DO-SYMBOLS was meant to include
symbols inherited from used packages. It never occurred to me that
explicit IMPORT statements could set up a situation in which a symbol
might show up twice unless you go to a lot of trouble to prevent this.
I also didn't think about shadowed symbols.
In my earlier note, I sent out my view of how to patch the existing
description. This is my view of "how it ought to be" rather than "what
the manual says". Does anyone object to adopting this as the "official"
interpretation? The only thing I'm uneasy about is letting DO-SYMBOLS
generate shadowed symbols, but I don't see any good alternative.
-- Scott
∂04-Mar-85 2036 HEDRICK@RUTGERS.ARPA Re: do-xxx-symbols
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 4 Mar 85 20:36:18 PST
Date: 4 Mar 85 23:34:48 EST
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: do-xxx-symbols
To: Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>" of 4 Mar 85 23:24:00 EST
I had forgotten that you wrote the chapter. I think that for the
author of a section to say "this is what I meant" is as authoritative
as we can reasonably expect. The only way I can see to guarantee only
one occurence, and no shadowed symbols is to hash each symbol before
passing it to the user. We did that in one implementation. It isn't
that horrible. Hashes are supposed to be fast. The idea is that you
keep a list of the packages that you have looked at so far. For
each candidate symbol, you look it up in all the hash tables you have
already used. If it is found, then you forget that symbol. If you
search the packages in the right order, this should do the right thing.
The cost of this depends upon how expensive the contents of the loop
are. It is going to perform N/2 hash lookups per symbol, where N is
the length of the use list. I conjecture that this will be on the
order of 3. 3 hash lookups isn't that much. But I certainly won't
do it unless I am told to. I can think of uses of both possible
semantics. If you remove duplicates, it is useful for things like
APROPOS. If you don't, it is useful for code that manipulates the
package system. E.g. you might use it to look for duplicates,
shadowed symbols, etc. So it is important to make sure we know
which thing is to be done. Don't say something like: well, we should
really only show him the symbol once, but some implementations may
not want to go to that work, so it's OK to ignore the problem.
-------
∂05-Mar-85 1541 godot!gls@AQUINAS Complex arc tangent
Received: from MIT-EDDIE.ARPA by SU-AI.ARPA with TCP; 5 Mar 85 15:41:02 PST
Received: by mit-eddie.ARPA (4.12/4.8) id AA06352; Tue, 5 Mar 85 18:35:36 est
Message-Id: <8503052335.AA06352@mit-eddie.ARPA>
Received: by godot with CHAOS id AA07351; Tue, 5 Mar 85 18:19:29 est
Date: Tuesday, 5 March 1985, 18:20-EST
From: Guy Steele <godot!gls@AQUINAS>
Subject: Complex arc tangent
To: mit-eddie!common-lisp%sail.arpa@GODOT
Cc: gls@AQUINAS
I spoke with Paul Penfield yesterday, and he says that he now agrees
with Kahan on the treatment of the branch cut for complex arc tangent.
He proposes to write some sort of joint letter recommending to the APL
and Common Lisp communities that this Kahan's definition of the branch
cut be adopted. This would mean a (small) change to Common Lisp if
we endorse it. Then everyone who cares at all about complex functions
in IEEE arithmetic will agree on the branch cuts. Are there any objections?
--Guy
∂07-Mar-85 1707 dzg@cmu-cs-spice.arpa file-length
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 7 Mar 85 17:07:05 PST
Apparently-From: dzg@CMU-CS-SPICE
Date: Thu 07 Mar 85 17:26:25-EST
From: dzg@CMU-CS-SPICE
To: common-lisp@SU-AI.ARPA
Subject: file-length
Message-ID: <6590.167185583.dzg>
I don't remember this being discussed on this bboard, so here it goes...
I think the definition of (file-length) on page 425 of the aluminum edition
leaves something to be desired. In particular, I object to the first
sentence: "<file-stream> must be a stream that is open to a file."
This requirement was probably dictated by the desire to return the length
in exactly the same units that were used to create the file. Reasonable as
this seems, it presents a lot of problems.
For one thing, it always forces you to write something like
(when probe-file FILE-NAME
(with-open-file
(little-dummy-stream FILE-NAME :direction :input)
... (file-length little-dummy-stream) ...
even when you don't want to read the file at all, but just see how big it
is. This is not exactly clear, I think.
Things are a lot worse, though, when you move into a networking environment.
One such environment, which I will use as an example, is Spice. Imagine
now you want to check the length of a remote file in Spice; imagine, say,
that you are worried about whether you'd be able to retrieve a huge
database file and fit in on your local disk. The Spice networking stuff is
perfectly happy with a "length of remote file" request, and will tell you
you do not have room. Imagine, though, that you wanted to do the same
thing from within Common Lisp. Well, you have to play the little
(with-open-file ...) game. BUT, in the Spice world (as in many, many other
worlds) this means you indeed want to read the file, all of it! As a
result, the file is shipped over to your machine, taking 5 minutes if you
are lucky. And if you are unlucky, the file will overflow your paging space
(not your file-system space, obviously, because you are NOT retrieving the
file to the file system, by golly, just checking its size!).
All of this is complete nonsense, obviously, when you could have gotten the
same reply in a millisecond if you just didn't have to open the file.
I suppose one could expand on the idea of (open :direction :probe), but
this still seems artificial. Why not just say that file-length takes "a
filename or a stream that is open to a file", like file-write-date, and
maybe let you specify what units you want file-length to return?
∂07-Mar-85 1707 dzg@cmu-cs-spice.arpa file-length
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 7 Mar 85 17:07:28 PST
Apparently-From: dzg@CMU-CS-SPICE
Date: Thu 07 Mar 85 17:26:25-EST
From: dzg@CMU-CS-SPICE
To: common-lisp@SU-AI.ARPA
Subject: file-length
Message-ID: <6590.167185583.dzg>
I don't remember this being discussed on this bboard, so here it goes...
I think the definition of (file-length) on page 425 of the aluminum edition
leaves something to be desired. In particular, I object to the first
sentence: "<file-stream> must be a stream that is open to a file."
This requirement was probably dictated by the desire to return the length
in exactly the same units that were used to create the file. Reasonable as
this seems, it presents a lot of problems.
For one thing, it always forces you to write something like
(when probe-file FILE-NAME
(with-open-file
(little-dummy-stream FILE-NAME :direction :input)
... (file-length little-dummy-stream) ...
even when you don't want to read the file at all, but just see how big it
is. This is not exactly clear, I think.
Things are a lot worse, though, when you move into a networking environment.
One such environment, which I will use as an example, is Spice. Imagine
now you want to check the length of a remote file in Spice; imagine, say,
that you are worried about whether you'd be able to retrieve a huge
database file and fit in on your local disk. The Spice networking stuff is
perfectly happy with a "length of remote file" request, and will tell you
you do not have room. Imagine, though, that you wanted to do the same
thing from within Common Lisp. Well, you have to play the little
(with-open-file ...) game. BUT, in the Spice world (as in many, many other
worlds) this means you indeed want to read the file, all of it! As a
result, the file is shipped over to your machine, taking 5 minutes if you
are lucky. And if you are unlucky, the file will overflow your paging space
(not your file-system space, obviously, because you are NOT retrieving the
file to the file system, by golly, just checking its size!).
All of this is complete nonsense, obviously, when you could have gotten the
same reply in a millisecond if you just didn't have to open the file.
I suppose one could expand on the idea of (open :direction :probe), but
this still seems artificial. Why not just say that file-length takes "a
filename or a stream that is open to a file", like file-write-date, and
maybe let you specify what units you want file-length to return?
∂07-Mar-85 1708 dzg@cmu-cs-spice.arpa file-length
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 7 Mar 85 17:07:56 PST
Apparently-From: dzg@CMU-CS-SPICE
'common-lisp@SU-AI.ARPA' βDate: Thu 07 Mar 85 17:26:25-EST
From: dzg@CMU-CS-SPICE
To: common-lisp@SU-AI.ARPA
Subject: file-length
Message-ID: <6590.167185583.dzg>
I don't remember this being discussed on this bboard, so here it goes...
I think the definition of (file-length) on page 425 of the aluminum edition
leaves something to be desired. In particular, I object to the first
sentence: "<file-stream> must be a stream that is open to a file."
This requirement was probably dictated by the desire to return the length
in exactly the same units that were used to create the file. Reasonable as
this seems, it presents a lot of problems.
For one thing, it always forces you to write something like
(when probe-file FILE-NAME
(with-open-file
(little-dummy-stream FILE-NAME :direction :input)
... (file-length little-dummy-stream) ...
even when you don't want to read the file at all, but just see how big it
is. This is not exactly clear, I think.
Things are a lot worse, though, when you move into a networking environment.
One such environment, which I will use as an example, is Spice. Imagine
now you want to check the length of a remote file in Spice; imagine, say,
that you are worried about whether you'd be able to retrieve a huge
database file and fit in on your local disk. The Spice networking stuff is
perfectly happy with a "length of remote file" request, and will tell you
you do not have room. Imagine, though, that you wanted to do the same
thing from within Common Lisp. Well, you have to play the little
(with-open-file ...) game. BUT, in the Spice world (as in many, many other
worlds) this means you indeed want to read the file, all of it! As a
result, the file is shipped over to your machine, taking 5 minutes if you
are lucky. And if you are unlucky, the file will overflow your paging space
(not your file-system space, obviously, because you are NOT retrieving the
file to the file system, by golly, just checking its size!).
All of this is complete nonsense, obviously, when you could have gotten the
same reply in a millisecond if you just didn't have to open the file.
I suppose one could expand on the idea of (open :direction :probe), but
this still seems artificial. Why not just say that file-length takes "a
filename or a stream that is open to a file", like file-write-date, and
maybe let you specify what units you want file-length to return?
∂07-Mar-85 2026 FAHLMAN@CMU-CS-C.ARPA file-length
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 Mar 85 20:26:37 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 7 Mar 85 23:26:01-EST
Date: Thu, 7 Mar 1985 23:25 EST
Message-ID: <FAHLMAN.12093275415.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: dzg@CMU-CS-SPICE.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: file-length
In-reply-to: Msg of 7 Mar 1985 17:26-EST from dzg at CMU-CS-SPICE
Dario,
I dimly remember some discussion of this before, but I don't have time
right now to try to track this down in the archives at SAIL.
I think it was specified that the file had to be open in order for
File-Length to work because a number of operating systems can't do it
any other way, so in portable code you can only count on the open-stream
case. There's no reason why non-brain-damaged systems like Spice could
not extend this call as you propose, or provide some alternative call
that as a non-standard extension. (The latter would make it easier to
catch non-portable usage, but users would have to remember two different
calls that do roughly the same thing -- confusing at best.)
-- Scott
∂07-Mar-85 2112 KMP@SCRC-STONY-BROOK.ARPA FILE-LENGTH
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 Mar 85 21:12:17 PST
Received: from SCRC-RIO-DE-JANEIRO by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 192195; Fri 8-Mar-85 00:10:59-EST
Date: Fri, 8 Mar 85 00:11 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: FILE-LENGTH
To: Fahlman@CMU-CS-C.ARPA, dzg@CMU-CS-SPICE.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12093275415.BABYL@CMU-CS-C.ARPA>,
<6590.167185583.dzg>
Message-ID: <850308001150.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Thu 07 Mar 85 17:26:25-EST
From: dzg@CMU-CS-SPICE
... For one thing, it always forces you to write something like
(when probe-file FILE-NAME
(with-open-file
(little-dummy-stream FILE-NAME :direction :input)
... (file-length little-dummy-stream) ...
even when you don't want to read the file at all, but just see how big it
is...
I agree this is lousy. I hate idiomatic usages like this. They're a pain
to read even when you recognize them and some people seem to have a talent
for picking ways to code the same idea in ways that are much less
intelligible than you could ever guessed could be devised...
Why not just let FILE-LENGTH take an optional ELEMENT-TYPE argument
to be used if the operation has to be simulated. If the file is already
open and is not of the given ELEMENT-TYPE, then signal an error if it's
not possible to convert from the given element type to the type the file
is open in. If the file is not open (ie, arg was a path instead of a stream),
then if the operating system primitively supports a file-length operation
on closed files and the ELEMENT-TYPE given is compatible with the type of
the file, then allow the system to optimize out the idiomatic OPEN given
above, and otherwise just simulate it in whatever way is convenient. Seems
to me like that would be portable.
-kmp
∂07-Mar-85 2130 KMP@SCRC-STONY-BROOK.ARPA DO-SYMBOLS finding shadowed symbols
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 Mar 85 21:30:01 PST
Received: from SCRC-RIO-DE-JANEIRO by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 192222; Fri 8-Mar-85 00:28:37-EST
Date: Fri, 8 Mar 85 00:29 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: DO-SYMBOLS finding shadowed symbols
To: Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12092488741.BABYL@CMU-CS-C.ARPA>
Message-ID: <850308002930.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Mon, 4 Mar 1985 23:24 EST
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
In my earlier note, I sent out my view of how to patch the existing
description. This is my view of "how it ought to be" rather than "what
the manual says". Does anyone object to adopting this as the "official"
interpretation? The only thing I'm uneasy about is letting DO-SYMBOLS
generate shadowed symbols, but I don't see any good alternative.
I'm also quite uneasy about this shadowed symbols issue. I see two situations:
The first is interactive. When working interactively, you resort to mapping
when the space of things you're frobbing is too large to do manually. In that
case, you want all the help you can get and writing the code to keep out
shadowed symbols may be something you forget or find very hard to write
correctly the first time (and you may only get one chance, unless you're
very careful). Undoing an incorrect mapping operation involving INTERN may
be massively hard.
The second is non-interactive. There you have the time to write and debug
an algorithm, but you may not be thinking about the shadowed symbol case and
may forget to write it in because it doesn't occur in the scenario you're
thinking about or whatever ... so you release code that mostly works but
has a bug sitting in it just waiting to happen.
If you make DO-SYMBOLS find symbols that are technically not accessible,
you'd better document it well. But personally, I don't advise it, even
if it makes coding it much harder. Better you, the implementor, spend the
time doing it once right than users spend the time over and over again
correcting for your ... I was going to say laziness, but that's obviously
the wrong word for people like all the CL implementors are. Nevertheless,
you get my point. "An ounce of prevention, ..." and all that.
As to worrying about duplicated symbols, that doesn't strike me as as big
a deal, though I'm open to arguments to the contrary.
-kmp
∂08-Mar-85 0827 FAHLMAN@CMU-CS-C.ARPA DO-SYMBOLS finding shadowed symbols
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Mar 85 08:27:04 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 8 Mar 85 11:26:08-EST
Date: Fri, 8 Mar 1985 11:25 EST
Message-ID: <FAHLMAN.12093406500.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: DO-SYMBOLS finding shadowed symbols
In-reply-to: Msg of 8 Mar 1985 00:29-EST from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
I've been having some second thoughts about shadowed symbols in
DO-SYMBOLS myself. It really is pretty dirty conceptually to have
DO-SYMBOLS supply anything that is not really accessible in the package.
I guess there are some ways that implementors could hack this without
incurring unacceptable costs. For example, we could set a bit
somewhere, either in the symbol itself or in the hash-table entry, for
any symbol that has ever been shadowed in any other package. For the
small minority of symbols with this bit set, we would have to do the
extra checking to make sure that it really is accessible; for all other
symbols, we could skip this. We wouldn't have to worry about un-setting
this bit if a symbol gets un-shadowed -- it's just a heuristic. There
are lots of variations on this theme. The point is that it need not
involve unacceptable overhead to eliminate shadowed symbols, though it
does make a bit of extra work for implementors. I guess I'd opt in this
case to keep the language clean rather than the implementation.
So my revised suggestion is that DO-SYMBOLS does provide all accessible
symbols including those inherited via USE-PACKAGE. It will present each
symbol at least once (may be more than once in cases of explicit
importantion), but will not present any symbols that are not really
accessible in the package in question due to shadowing.
-- Scott
∂08-Mar-85 1140 HEDRICK@RUTGERS.ARPA Re: file-length
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 8 Mar 85 11:40:41 PST
Date: 8 Mar 85 14:39:47 EST
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: file-length
To: common-lisp@SU-AI.ARPA
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>" of 7 Mar 85 23:25:00 EST
Tops-20 requires a GTJFN before we can find file length. But we can
certainly implement it by opening the file temporarily inside
file-length. So you shouldn't stop just because some OS's may
need to open the file.
However you should consider that this may lead to ambiguity because of
version numbers. Consider the following code sequences:
(check-attributes "foo.bar")
(if (attributes-look-good)
(read-file "foo.bar"))
or
(write-file "foo.bar")
(look-at-attributes "foo.bar")
The problem with both of these is that some other program may create
a new version of foo.bar in the interim. If we say that you can
look at attributes only for an open stream, then people are more
likely to open the file once, and do their I/O and attribute-checking
on the open stream. On TOPS-20, we could get the same effect by
encouraging people to do TRUE-NAME the first time they refer to a
file. Then they can be sure they are always talking about the same
one. But on Unix this wouldn't work.
So the safest thing is probably to keep the current definition.
If somebody really does want to look at the length of a file and
will never be opening it, you can define a macro to allow a
syntax like
(with-temporarily-open-file "foo.bar" x (file-length x))
-------
∂08-Mar-85 1442 RAM@CMU-CS-C.ARPA file-length
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Mar 85 14:42:10 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Fri 8 Mar 85 17:41:31-EST
Date: Fri, 8 Mar 1985 17:41 EST
Message-ID: <RAM.12093474853.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: file-length
In-reply-to: Msg of 8 Mar 1985 14:39-EST from Charles Hedrick <HEDRICK at RUTGERS.ARPA>
Your argument is bogus, since there is no guarantee that arbitrary
operating systems will prevent a file from being overwritten while you
have it open. In particular, Spice has no concept of an open file,
thus no assurance of consistency. Unix has no guarantee of fileystem
consistency of any kind, so worrying about it is a lost cause.
Rob
∂12-Mar-85 0710 hpfclp!paul%hplabs.csnet@csnet-relay.arpa float-digits
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 12 Mar 85 07:10:19 PST
Received: from hplabs by csnet-relay.csnet id ad07182; 12 Mar 85 9:59 EST
Date: Tue, 12 Mar 85 02:53:42 pst
From: hpfclp!paul%hplabs.csnet@csnet-relay.arpa
MMDF-Warning: Parse error in preceding line at CSNET-RELAY.ARPA
Received: by HP-VENUS id AA29106; Tue, 12 Mar 85 02:53:42 pst
Message-Id: <8503121053.AA29106@HP-VENUS>
To: hplabs!common-lisp@su-ai.ARPA
Subject: float-digits
Source-Info: From (or Sender) name not authenticated.
What is the result of (float-digits 0.0)?
Why isn't "float-radix" a constant?
Paul Beiser
Hewlett-Packard
Ft. Collins, Colorado
uucp: ...{ihnp4,hplabs}!hpfcla!paul
arpa: "hpfclp!paul%hplabs.csnet"@csnet-relay
∂12-Mar-85 0748 FAHLMAN@CMU-CS-C.ARPA float-digits
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Mar 85 07:47:51 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 12 Mar 85 10:47:11-EST
Date: Tue, 12 Mar 1985 10:47 EST
Message-ID: <FAHLMAN.12094447991.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: hpfclp!paul%hplabs.csnet@CSNET-RELAY.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: float-digits
In-reply-to: Msg of 12 Mar 1985 05:53-EST from hpfclp!paul%hplabs.csnet at csnet-relay.arpa
Paul,
Floating point hackery is not my specialty, but maybe I can give you a
quick answer that will stand unless one of the real experts pops up to
contradict me.
What is the result of (float-digits 0.0)?
Float-digits tells you how many radix-b digits there are in the
representation of the fractional part (the "significand") of the type of
number you feed it. It doesn't care at all about the value of the
argument, just about which type of float it is. So in this case, it
tells you the number of digits (usually bits) in the significand of a
number of the default floating type, as controlled by
*read-default-float-format*.
Why isn't "float-radix" a constant?
Float-radix may in principle be different for different types of floats
in the same implementation, though I don't know of any existing
implemenation that does this. By making it a function, we allow the
user to ask for the float-radix of some particular type of number: the
type of the argument.
-- Scott
∂19-Mar-85 0056 JLW DO-SYMBOLS: duplicates and shadowings
To: Fahlman@CMU-CS-C.ARPA
CC: common-lisp@SU-AI.ARPA
My reading of the do-symbols documentation was that "the symbols of a
package" was a colloquialism for "symbols accessible in a package", and
hence it should include the inherited symbols -- the Spice code I saw
appeared to be buggy on that score.
Perhaps we should identify the needs and the costs of the two components
in your "revised" suggestion.
1) I have no need [currently!] for removal of duplicates, but would be
willing to listen to someone who claims such a need. As for cost
of implementing this, it sounds like Hedricks 3+ hashtable lookups
[on average] per symbol "done" is th best contender. That could
easily make some simple cases an order of magnitude slower.
2) In at least one case I know of, it would be rather disastrous for a
shadowed symbol to be "done", in addition to the shadowing counterpart.
As for cost of removing shadowed potential inheritees, I would like
to hear some estimates on the average number of shadowing symbols
in a package that has an earnest need for some shadowing. The one
example I can think of off-hand is a language emulator which is a
variant on Common Lisp -- the non-standard, conflicting definitions
have to be shadowed; in the example I'm thinking of, it is still less
than 100 shadowings. The answer to this question may affect the
strategy for shadowed-symbol omission, and hence the cost.
Just for the record, one may have duplicates arise because the same
symbol is inherited from several different used packages; IMPORT is not
the only villain here.
-- JonL --
∂19-Mar-85 0114 JLW File-length on pathnames
To: dzg@CMU-CS-SPICE.ARPA
CC: Fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA
I believe that Interlisp, at one time, limited the use of the file-length
equivalent to open file; this turned out to be very inconvenient, and was
changed [maybe about the time I began working for Xerox, three years ago].
A lesson to be learned: no matter what the implementation cost, it will
ultimately be more costly *not* to provide that capability to the user;
somebody's example of how Spice would react to the opening of a huge
remote file shows that this is the sort of thing that ought to be done
by the system implementor.
As for potential inconsistencies due to multi-user access to a shared
file system -- consider the two alternatives: (A) Smooth results, with
only an epsilonic probability that they will be ragged [non "Smooth"] due
to the multi-user, shared access, or (B) nothing. While opting for (A),
I don't consider myself a gambler.
By the way, what kind of distributed file system does Spice have? Isn't
it rather primitive to provide no byte-level or page-level access to
remote files? It sounds from the previous discussions that only an FTP
like facility is provided.
-- JonL --
∂19-Mar-85 0717 FAHLMAN@CMU-CS-C.ARPA DO-SYMBOLS: duplicates and shadowings
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Mar 85 07:17:43 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 19 Mar 85 10:05:40-EST
Date: Tue, 19 Mar 1985 10:05 EST
Message-ID: <FAHLMAN.12096275453.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Jon White <JLW@SU-AI.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: DO-SYMBOLS: duplicates and shadowings
The Spice Lisp system has now been changed by Rob Maclachlan so that
DO-SYMBOLS does the right thing (according to my latest proposal):
inherited symbols are presented, there is no special effort to eliminate
duplicates, and shadowed symbols are eliminated. As I understand it,
the latter is accomplished by keeping track of which packages contain
*any* shadowed symbols, and for symbols exported by these packages doing
what amounts to a call to FIND-SYMBOL on each candidate. Rob tells me
that even when this extra checking is being done, it doesn't hurt us too
much in speed.
-- Scott
∂19-Mar-85 1344 RAM@CMU-CS-C.ARPA File-length on pathnames
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Mar 85 13:43:52 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Tue 19 Mar 85 16:42:55-EST
Date: Tue, 19 Mar 1985 16:42 EST
Message-ID: <RAM.12096347756.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Jon White <JLW@SU-AI.ARPA>
Cc: common-lisp@SU-AI.ARPA, dzg@CMU-CS-SPICE.ARPA, Fahlman@CMU-CS-C.ARPA
Subject: File-length on pathnames
In-reply-to: Msg of 19 Mar 1985 04:14-EST from Jon White <JLW at SU-AI.ARPA>
The official party line is that Spice has no concept of a host.
In order to access a file on another machine, you embed that
filesystem into your filesystem. There is no reasonable way to talk
about access at the byte level or page level, since the only file I/O
primitives are reading and writing an entire file. This works fairly
well, since the file is only mapped when you read it, and the reading
not actually done until you touch the page. There is currently work
in progress to permit mapping of files and memory over the network.
When this capability exists, the problem will go away.
I find the restriction on FILE-LENGTH extremely silly. As near as
I can tell, the argument for requiring the restriction is the
following:
- Some operating systems require an operation (which they may nor may
not call open, and is in any case not probably not identical in
semantics to the Common Lisp open) to be done before the length of
a file can be determined.
- This "operating system open" call may have some requirement for
exclusive access. If some other process has the file open, then
the call to FILE-LENGTH may wait or fail.
- It is somehow more intuitive to have OPEN wait or fail than to
have FILE-LENGTH wait or fail.
I think that if there is any implicit guarantee in the CLM
filesystem chapter that certain calls may not wait or fail whenever
they feel like it, then it is bogus. There is no way the CLM can hope
to describe the semantics of arbitrary filesystems, let alone the
real-time properties.
Rob
∂19-Mar-85 1855 FAHLMAN@CMU-CS-C.ARPA [Gall: Bug Report]
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Mar 85 18:55:00 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 19 Mar 85 21:54:17-EST
Date: Tue, 19 Mar 1985 21:53 EST
Message-ID: <FAHLMAN.12096404394.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: [Gall: Bug Report]
Here are some Common Lisp questions sent to me by Nick Gall of Gold
Hill. I'll take a crack at answering some of them when I get the time,
if nobody else beats me to this.
-- Scott
***************************************************************************
Date: Tuesday, 19 March 1985 13:39-EST
From: Nick Gall <Gall at MIT-MULTICS.ARPA>
To: Fahlman
Re: Bug Report
Posted-Date: 19 Mar 85 13:41 EST
Acknowledge-To: Nick Gall <Gall@MIT-MULTICS.ARPA>
These comments are presented in the style suggested by Postscript
to the Ada (TM) Language Reference Manual. The format of the
header is as follows:
!section SECTION#(PARAGRAPH#) NAME ISO-DATE
!version REFERENCE-MANUAL-VERSION-NAME
!topic SUMMARY-OF-COMMENT
The Ada RM states that,
The topic line should contain a one line summary of the
comment. This line is essential, and you are kindly asked to
avoid topics such as "Typo" or "Editorial comment" which will
not convey any information when printed in a table of
contents. As an example consider:
!topic Subcomponents of constants are constants
Note also that nothing prevents the topic line from including
all the information of a comment, as in the following topic
line:
!topic Insert: "... are {implicitly} defined by a
subtype declarartion"
-----------------------------------------------------------------
!section None Nick Gall 85-03-19
!version Digital Press 1984
!topic Paragraphs should be numbered
Paragraphs should be numbered as in the Ada (TM) Language
Reference Manual. This would make identification of particular
paragraphs in discussions much simpler.
-----------------------------------------------------------------
!section 14.1(2) Nick Gall 85-03-19
!version Digital Press 1984
!topic Copying arrays
Although functions such as SUBSEQ state that the copy made of an
array is of the same type, they say nothing of the two other array
attributes, fill pointer and adjustable.
The question is, "Should copied arrays share these attributes
with their originals, or should they be simple?"
The answer should be stated in the standard.
I think the best solution is to make simple copies by default,
and allow an optional or keyword arg. to specify that all
attributes should be copied.
-----------------------------------------------------------------
!section 18.3(2) Nick Gall 85-03-19
!version Digital Press 1984
!topic Implied copying in the trim functions
Although it is implied that the result of the string `trim'
functions is a copy of the original strings, it is not explicitly
stated. Since all the other functions which can potentially make
copies of strings/arrays state this explicitly (e.g. SUBSEQ,
CONCATENATE, SUBSTITUTE), the trim functions should also.
-----------------------------------------------------------------
!section 18.3(2) Nick Gall 85-03-19
!version Digital Press 1984
!topic Implied copying in the STRING-{UP | DOWN}CASE functions
Although it is implied that the result of the {up | down}
functions is a copy of the original strings, it is not explicitly
stated. Since all the other functions which can potentially make
copies of strings/arrays state this explicitly (e.g. SUBSEQ,
CONCATENATE, SUBSTITUTE), the {up | down} functions should also.
-----------------------------------------------------------------
!section 9.1(6) Nick Gall 85-03-19
!version Digital Press 1984
!topic Pervasiveness of declarations over FLET and LABELS
Example:
(defun the-many-function-names-foo (x)
(declare (inline foo))
(foo x) ; First call of FOO
(flet ((foo (y z) (zap z y)))
(foo x x)) ; Second call of FOO
(foo x)) ; Third call of FOO
According to the paragraph in question: "Declarations that do not
concern themselves with variable bindings are pervasive,
affecting ALL CODE IN THE BODY OF THE SPECIAL FORM." Thus, the
second call to FOO will be open-coded; in spite of the fact that
the second call of FOO refers to a function which is totally
unrelated (except by name) to the FOO referred to in the other
two calls.
To prevent this, one has to provide a declaration
within the FLET form:
...
(flet ((foo (y z) (zap z y)))
(declare (notinline foo))
...)
...
But what if this FLET were the expansion of a macro? How is the
macro expansion function supposed to know which pervasive
declarations will affect the functional objects specified in the
FLET?
In an analogous case concerning special variables instead of
function names, no such redeclaration is necessary:
(defun the-many-variables-foo (foo)
(declare (special foo))
(fram foo) ; dynamic binding
(let ((foo (boop)))
(frab foo)) ; local lexical binding
(zoop foo)) ; dynamic binding
Declarations concerning function names should be treated as
special variable declarartions are: references are pervasively
affected, but not bindings.
The last paragraph in each of the function name declarations
(e.g. FUNCTION, INLINE, etc.) which begins, "Note that the rules
of lexical scoping...", suggests that function names and special
variables ARE treated analogously. If this is so, it should be
made explicitly clear in section 9.1.
-----------------------------------------------------------------
!section 9.1(12) Nick Gall 85-03-19
!version Digital Press 1984
!topic Non-Top-Level use of PROCLAIM
Can PROCLAIM be used, other than at top-level? Since DEFVAR,
etc., are proclamations and can be used at other than top-level,
the answer to this question seems to be `yes'.
Is PROCLAIM a `declaration', i.e., must it appear only where a
declaration is allowed? Since it is allowed at top-level (unlike
DECLARE), and it is a function, and since the other proclaiming
forms (e.g. DEFVAR, etc.) could not be considered declarations
(since they perform evaluation and assignment), the answer must
be no.
Then what is the effect of using PROCLAIM (or one one the other
proclaiming forms) in the middle of a function? For example:
(defun foo (a) (zap a) (proclaim '(special a)) (zark a))
Does the first reference to A refer to the local binding? Does
the second reference refer to the global?
Some mention of the effects of the non-top-level use of PROCLAIM
and the other proclaiming forms should be made.
-----------------------------------------------------------------
!section 7.5(14) Nick Gall 85-03-19
!version Digital Press 1984
!topic Scope and Extent of local function names
NOTE: See 9.2 (ftype, function, inline).
Example:
(DEFUN CREATE-MAKEP (MAKE)
(FLET ((CAR (SYMBOL) (GET SYMBOL 'AUTOMOBILE)))
#'(LAMBDA (OWNER) (EQ MAKE (CAR OWNER)))))
(SETQ FOO (CREATE-MAKEP 'HONDA))
(FUNCALL FOO 'BILL) => ?????
Question: What does CAR refer to when it is used in the closure
returned by CREATE-MAKEP? I.E., What is the scope and
extent of the binding of a local function name to a
functional object?
Section 7.1(1) states that "There are two spaces of variables in
Common Lisp, in effect: ordinary variables and function names."
And the function name binding control structures appear in the
section entitled "Establishing New Variable Bindings".
I suggest that Common Lisp go all the way, and allow a
SPECIAL-FUNCTION-NAME declaration that would be analogous to the
SPECIAL declaration for "ordinary" variables.
Such a concept would make the idea of
ordinary-variable/function-name binding and assignment much more
consistent.
-----------------------------------------------------------------
!section 5.2.2(4) Nick Gall 85-03-19
!version Digital Press 1984
!topic Lambda variables with the same `name'
Ex. 1:
(lambda (a a) (values a))
Ex. 2:
;; Assume (not (eq p1::a p2::a))
(lambda (p1::a p2::a) (values p1::a p2::a))
Ex. 3:
;; Assume (eq p1::a p2::a)
(lambda (p1::a p2::a) (values p1::a p2::a))
1. Is Ex. 1 legal? If so, which args., value is returned?
My answer: No, and the CLRM should state this.
2. Is Ex. 2 legal?
My answer: Yes.
3. Is Ex. 3 legal?
My answer: No. it is just like Ex. 1.
The point that Exs. 2 + 3 point out is that it is the symbols
THEMSELVES that name variables, not their (qualified)
print-names. This distinction should be pointed out.
This same comment applies to all the other environment
establishing functions (section 7.5).
-----------------------------------------------------------------
!section 5.3.2(7) Nick Gall 85-03-19
!version Digital Press 1984
!topic Redeclaring Constants with DEFCONSTANT
It should be mentioned in this paragraph, as it is in 5.1.2(6),
that,
Constant symbols defined by DEFCONSTANT also become reserved
and may not be further assigned to or bound (although they may be
redefined, if necessary, by using DEFCONSTANT again).
-----------------------------------------------------------------
!section 7.8.5(3) Nick Gall 85-03-19
!version Digital Press 1984
!topic Are identical TAGs legal?
If so, which one is gone to? If not, it should be stated.
-----------------------------------------------------------------
!section 7.8.5(3) Nick Gall 85-03-19
!version Digital Press 1984
!topic Items which are not symbols, integers, or lists in
a TAGBODY
The sentence,
An item in the body may be a symbol or an integer, in which
case it is called a TAG, or ... a list, in which case it is
called a STATEMENT.
Does this mean that any other atom is illegal? If so, it should
be stated.
-----------------------------------------------------------------
!section 9.1(10) Nick Gall 85-03-19
!version Digital Press 1984
!topic Replace: "... the parameter {of} NONSENSE named Z."
-----------------------------------------------------------------
!section 23.1.2(11) Nick Gall 85-03-19
!version Digital Press 1984
!topic Replace: "... if no syntactically correct {namestring}
was seen."
-----------------------------------------------------------------
!
-----------------------------------------------------------------
!section 10.3(9) Nick Gall 85-03-19
!version Digital Press 1984
!topic Which bindings are copied by COPY-SYMBOL?
"the initial value and function-definition of the new symbol
will be the same as those of SYM..."
Does this mean that the (dynamic) value of the variable
referred to by SYM, at the point where COPY-SYMBOL symbol is
invoked, is copied? Or, does it mean that the `initial', i.e.
global value of the special variable named by SYM is copied?
Although the wording seems to suggest the latter, it should be
made clearer.
The same questions and suggestion applies to the
function-definition copied by COPY-SYMBOL.
-----------------------------------------------------------------
!section 15.2(39) Nick Gall 85-03-19
!version Digital Press 1984
!topic The effect of NCONC on '() arguments
"The arguments are changed, rather than copied."
Surely, this does not apply to the arguments which are empty
lists. Also, the last argument is NOT changed, right?
Are dotted-lists allowed? If so, the result of a call such as,
(NCONC '(1 2 . 3) NIL)
should be made explicit.
-----------------------------------------------------------------
!section 15.2(55) Nick Gall 85-03-19
!version Digital Press 1984
!topic What may N be in BUTLAST?
MUST N be a non-negative integer? Or can it be negative (with a
neg. N having the same effect as a zero N)? The constraints on
the type and range of N should be made explicit.
-----------------------------------------------------------------
!section 15.2(57) Nick Gall 85-03-19
!version Digital Press 1984
!topic When is LIST modified in NBUTLAST?
Shouldn't the condition, "If the LIST has fewer than N
elements..." read, "If the LIST has N or fewer elements...".
-----------------------------------------------------------------
!section 15.5(8) Nick Gall 85-03-19
!version Digital Press 1984
!topic Is (TAILP NIL list) true or false for every list?
"This preicate is true if SUBLIST is a sublist of LIST (i.e. one
of the conses that makes up LIST)." According to this criterion,
NIL is not a sublist to any list since it is not a cons.
"...TAILP is true if (NTHCDR n list) is sublist, for some value
of N." According to this definition NIL is a sublist of every
list, since the (NTHCDR (LENGTH list) list) is NIL for every
LIST.
Although a phrase in the definition of LDIFF, "If SUBLIST is not
a tail of LIST (and in particular if SUBLIST is NIL)," seems to
indicate that NIL is NOT a sublist (or tail) of any list, this
should be stated explicitly in the definition of TAILP.
-----------------------------------------------------------------
!section 20.1(7) Nick Gall 85-03-19
!version Digital Press 1984
!topic Is *APPLYHOOK* funcalled for special forms?
"The variable *APPLYHOOK* ... is used when a function is about to
be applied to arguments." Does `function' refer to a functional
object which is in fact a function (i.e., its args. are evaled
before it is called), or does it refer to any functional object
(e.g., `special' functional objects)?
Later in the paragraph, it is stated that,
The apply hook function is used only for application of
ordinary functions within eval. It is not used for
applications via apply, or funcall, for applications by such
functions as map or reduce, or for invocation of
macro-expansion functions...
This paragraph does not really address the "application of
ordinary functions within eval" but rather the "ordinary
application of functions by eval." Also it does not clarify the
action taken for special forms.
This paragraph should be made clearer.
-----------------------------------------------------------------
!section 21.3(7) Nick Gall 85-03-19
!version Digital Press 1984
!topic What does CLOSE Return?
I think it should return the STREAM it was given to close. This
would make it symmetric with OPEN: OPEN returns an open stream,
CLOSE returns a closed stream.
-----------------------------------------------------------------
!section 20.1(last-1) Nick Gall 85-03-19
!version Digital Press 1984
!topic Is nil declared by defconstant?
...all constant symbols declared by DEFCONSTANT, such as NIL,
T, and PI.
If NIL is declared by DEFCONSTANT then it can legally be
redefined according to section 5.1.2(last):
Constant symbols defined by DEFCONSTANT ... may be redefined,
if necessary, by using DEFCONSTANT again[].
Is such an interpretation correct?
-----------------------------------------------------------------
!section 4.8(1) Nick Gall 85-03-19
!version Digital Press 1984
!topic The meaning of the word `convert'
Does coerce `convert' (i.e., change the type bits) and return the
original object (or the pointer if typed pointers are supported)
when possible (e.g., coercing a string to an array of
(unsigned-byte 8) in some implementations); or does coerce ALWAYS
create and return a new `equivalent' object; or does the Common
Lisp spec. not define this?
-----------------------------------------------------------------
!section 5.3.2(7) Nick Gall 85-03-19
!version Digital Press 1984
!topic Lexical variable with the same name as a named constant
A named constant is declared using DEFCONSTANT. DEFCONSTANT
PROCLAIMs that a symbol always names a special variable (which
happens to have a fixed value). This proclamation applies to ALL
bindings and references. Therefore, after such a proclamation,
no lexical variable with such a name can be used.
If this is the case, when would the compiler ever have the
opportunity to
...issue warnings about bindings of the lexical variable of
the same name [as a name declared by DEFCONSTANT to be
constant].
∂19-Mar-85 2212 cork%umass-cs.csnet@csnet-relay.arpa Implementation of MAP, SOME, EVERY, etc...
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 19 Mar 85 22:12:08 PST
Received: from umass-cs by csnet-relay.csnet id af11355; 20 Mar 85 1:07 EST
Date: Tue, 19 Mar 85 11:58 EST
From: Dan Corkill <cork%umass-cs.csnet@csnet-relay.arpa>
To: common-lisp@su-ai.ARPA
Subject: Implementation of MAP, SOME, EVERY, etc...
There is an easily made implementation error in MAP, SOME, EVERY, etc.
The published semantics indicate that these functions use the length of
the shortest argument sequence to determine how many iterations to
perform (and in this way parallel the semantics of mapc, mapcar, etc.).
Thus it would appear that:
(map 'list '+ '(1 2 3) (star 2))
where star builds a circular list of its argument should be legal and
return => (3 4 5).
Implementations that use length to check the length of argument sequences
will break on such a call.
Dan Corkill
(Cork@UMass)
∂19-Mar-85 2228 REM@IMSSS Default attributes of copy due to SUBSEQ
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Mar-19 22:24:02 PST (=GMT-8hr)
Date: 1985 March 19 21:23:38 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132100055002.G0396
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:common-lisp@SU-AI.ARPA
CC:Gall@MIT-MULTICS.ARPA
Subject: Default attributes of copy due to SUBSEQ
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM@MIT-MC.ARPA
> Date: Tuesday, 19 March 1985 13:39-EST
> From: Nick Gall <Gall at MIT-MULTICS.ARPA> (via Fahlman)
> Posted-Date: 19 Mar 85 13:41 EST
>
> !section 14.1(2) Nick Gall 85-03-19
> !version Digital Press 1984
> !topic Copying arrays
>
> Although functions such as SUBSEQ state that the copy made of an
> array is of the same type, they say nothing of the two other array
> attributes, fill pointer and adjustable.
>
> The question is, "Should copied arrays share these attributes
> with their originals, or should they be simple?"
>
> The answer should be stated in the standard.
I agree completely so far. I would think it would copy those other
attributes, rather than clobber them to SIMPLE when making the copy,
but on the other hand, I'm not really sure.
But clearly the manual should say, and probably an extra argument
should be available to override the default.
∂19-Mar-85 2228 REM@IMSSS What should CLOSE return? Closed-channel-object, or truefilename.
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Mar-19 22:24:42 PST (=GMT-8hr)
Date: 1985 March 19 22:10:06 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132100055052.G0446
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:common-lisp@SU-AI.ARPA
CC:Gall@MIT-MULTICS.ARPA
Subject: What should CLOSE return? Closed-channel-object, or truefilename.
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM@MIT-MC.ARPA
> !section 21.3(7) Nick Gall 85-03-19
> !version Digital Press 1984
> !topic What does CLOSE Return?
>
> I think it should return the STREAM it was given to close. This
> would make it symmetric with OPEN: OPEN returns an open stream,
> CLOSE returns a closed stream.
That's not symmetric, that's coercive. OPEN and CLOSE are like
matching parenthesis, one does it and the other undos it except for
a residual side-effect. OPEN takes a name and returns an I/O channel
(at the LISP level, an object that can be name an active stream of
data). CLOSE takes an I/O channel and should return a name to be
symmetric with OPEN. This would be an opportune time to solve race
conditions where several users are making different versions of the
same file at the same time by the trick of writing a temporary file
and then renaming it during the CLOSE. At CLOSE the version number is
determined, and at that moment before somebody can create a later
version the lisp CLOSE function obtains the true filename of the
particular version we created.
∂19-Mar-85 2228 REM@IMSSS Length of currently-open-for-write file is ambiguous or meaningless
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Mar-19 22:23:35 PST (=GMT-8hr)
Date: 1985 March 19 20:54:07 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132100054747.G0371
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To: common-lisp@SU-AI.ARPA
CC: RAM@CMU-CS-C.ARPA
Subject: Length of currently-open-for-write file is ambiguous or meaningless
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM@MIT-MC.ARPA
> Date: Tue, 19 Mar 1985 16:42 EST
> From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
> Subject: File-length on pathnames
>...
> - This "operating system open" call may have some requirement for
> exclusive access. If some other process has the file open, then
> the call to FILE-LENGTH may wait or fail.
> - It is somehow more intuitive to have OPEN wait or fail than to
> have FILE-LENGTH wait or fail.
>
> I think that if there is any implicit guarantee in the CLM
> filesystem chapter that certain calls may not wait or fail whenever
> they feel like it, then it is bogus. ...
I agree completely with RAM, in fact I'd like to present a case that
FILE-LENGTH is meaningless when a file is open for write access by
self or by other task/user, and thus that it's quite reasonable for
FILE-LENGTH to fail (signal an error). FILE-LENGTH is supposed to tell
the length of the disk file, right? Well, if you're in the middle of
modifying it, either by replacing it with a new version you're in the
midst of creating, or by destructively modifying it and by changing
the directory attributes (length, disk record map, etc.), what exactly
do you mean by the length?
(1) Length that it was before you started to modify it (that info
probably already clobbered in case of destructive modification,
although available if making new version which is not yet installed).
(2) Length it will be when you close it (not known yet).
(3) Some sort of momentary length as it currently exists (does that
include I/O buffers which have been partially filled in RAM but not
yet written to disk? buffers that have been written to disk but not
yet included in directory? buffers that have been unwritten by
decreasing the end-of-file pointer but haven't yet been expunged and
thus still are part of the file in some sense that if the system
crashed a wizard could recover them?)
Perhaps the function should include an extra argument that tells
whether you want the old info or a failure (error signal) or a
wait-for-close then new info or the instantaneous-guess info in such
an ambiguous case? Probably the default should be failure if you don't
supply the &OPTIONAL or &KEYWORD argument. If a file is open only for
read, I think there's no problem, the file can always be sized? (Or in
a network environment, perhaps there is only one copy of the file at
any time, and to size it you have to first move it to your site, which
means nobody else can have it open for read elsewhere? In such a
network it might fail even in case of open for read by somebody else
on another site, and the extra argument might be needed to say what to
do to resolve the problem.)
Since even in the case of a file you have open yourself the above
ambiguity can occur, with FILE-LENGTH of an I/O channel signalling an
error, I see no problem with implementing FILE-LENGTH applied to
filenames, where it's completely reasonable for the programmer to
have to be aware it might signal an error at random times when
somebody (yourself included) happens to have the file open for write.
∂20-Mar-85 0132 RAM@CMU-CS-C.ARPA Length of currently-open-for-write file is ambiguous or meaningless
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 01:32:15 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 20 Mar 85 04:31:46-EST
Date: Wed, 20 Mar 1985 04:31 EST
Message-ID: <RAM.12096476811.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: REM@MIT-MC.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Length of currently-open-for-write file is ambiguous or meaningless
In-reply-to: Msg of 1985 Mar 19 20:54:07 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>
I think that file-length of a stream that is open for write is
perfectly meaningful. file-length is the file-position of EOF. In
the presence of multiple concurrent writers, the result may be
ill-defined, but if that is the case, you are in bad trouble anyway.
The meaning of File-Length on the name of a file which is open for
write seems operating system dependant, and should be undefined. Since
it is in fact this case which I understand to be the basis for not
allowing file-length on file names, taking this stand would dispose of
any problems.
Rob
∂20-Mar-85 0141 RAM@CMU-CS-C.ARPA Default attributes of copy due to SUBSEQ
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 01:41:32 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 20 Mar 85 04:40:52-EST
Date: Wed, 20 Mar 1985 04:40 EST
Message-ID: <RAM.12096478471.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: REM@MIT-MC.ARPA
Cc: common-lisp@SU-AI.ARPA, Gall@MIT-MULTICS.ARPA
Subject: Default attributes of copy due to SUBSEQ
In-reply-to: Msg of 1985 Mar 19 21:23:38 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>
The semantics that I favor (and those implemented by Spice Lisp)
are that every Common Lisp function which returns an array returns a
simple array unless the function is make-array or one of the arguments
is eq to the result. This has the advantage of being a simple
specification, and also allows the compiler to do more interesting
type-inference.
Rob
∂20-Mar-85 0144 RAM@CMU-CS-C.ARPA Default attributes of copy due to SUBSEQ
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 01:44:21 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 20 Mar 85 04:43:45-EST
Date: Wed, 20 Mar 1985 04:43 EST
Message-ID: <RAM.12096478990.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: REM@MIT-MC.ARPA
Cc: common-lisp@SU-AI.ARPA, Gall@MIT-MULTICS.ARPA
Subject: Default attributes of copy due to SUBSEQ
In-reply-to: Msg of 1985 Mar 19 21:23:38 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>
Well, I guess that's a bit excessively simple if read literally.
It could be "every function that creates an array creates a simple
array unless that function is make-array".
Rob
∂20-Mar-85 0208 RAM@CMU-CS-C.ARPA Implementation of MAP, SOME, EVERY, etc...
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 02:08:14 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 20 Mar 85 05:07:23-EST
Date: Wed, 20 Mar 1985 05:07 EST
Message-ID: <RAM.12096483296.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Dan Corkill <cork%umass-cs.csnet@CSNET-RELAY.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Implementation of MAP, SOME, EVERY, etc...
In-reply-to: Msg of 19 Mar 1985 11:58-EST from Dan Corkill <cork%umass-cs.csnet at csnet-relay.arpa>
I think that a sufficiently fascist interpretation of the CLM
would say that this is erroneous. Nowhere in the CLM is it stated
that a circular list is the same as an infinite list, and it is
unlikely that any implementation would consistently have those
semantics. Setting element 537 of an infinite list should only
change element 537. Setting element 537 in a one-element circular
list would probably change all the elements if it terminates.
The definition of a normal list in the Lists chapter is one
terminated by NIL. By this definition, a circular list is a dotted
list. I believe that there was a decision at one point that functions
which use lists as sequences (a superset of the sequence functions)
are allowed to complain about dotted lists. This is implied by the
statement that Endp is the canonical list-end predicate.
Rob
∂20-Mar-85 2032 DDYER@USC-ISIB.ARPA Re: Implementation of MAP, SOME, EVERY, etc...
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 20:32:02 PST
Date: 20 Mar 1985 20:07:05 PST
Subject: Re: Implementation of MAP, SOME, EVERY, etc...
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12096483296.BABYL@CMU-CS-C.ARPA>
I disagree with RAM; Imposing the requirement that all lists
passed to MAPxxx be "proper" imposes an unnecesary burden on
the use of mapping functions; The programmer shouldn't have to
know anything about the lists passed to MAPxxx except that the
sortest list is a proper list.
Besides, it would be an extremely poor implementation technique
to take LENGTH of all the lists before starting work -- I would say
that system functions should NEVER use LENGTH unless it is otherwise
known that the functin in question will inspect every element of the
list anyway, both because lists might legitimately be "improper",
and because lists can legitimately be very long, which makes
LENGTH wasteful.
-------
∂20-Mar-85 2053 RAM@CMU-CS-C.ARPA Query (FILE-LENGTH in particular) of file by name when open
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 20:52:45 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 20 Mar 85 23:21:39-EST
Date: Wed, 20 Mar 1985 21:30 EST
Message-ID: <RAM.12096662208.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: REM@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA
Subject: Query (FILE-LENGTH in particular) of file by name when open
In-reply-to: Msg of 1985 Mar 20 02:44:29 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>
I don't think we can require it to signal an error, since some
operating systems don't provide any way to tell if a file is open.
In Spice, for example, there is no open call, so the question isn't
even meaningful. I think that all we can say is that it is an error,
and implementations are encouraged to detect it, or at least not
delete all you files and crash the machine.
Rob
∂20-Mar-85 2052 RAM@CMU-CS-C.ARPA [REM: Query (FILE-LENGTH in particular) of file by name when open]
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 20:52:25 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 20 Mar 85 23:21:37-EST
Date: Wed, 20 Mar 1985 21:25 EST
Message-ID: <RAM.12096661456.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: [REM: Query (FILE-LENGTH in particular) of file by name when open]
Date: 1985 March 20 02:44:29 PST (=GMT-8hr)
From: Robert Elton Maas <REM at IMSSS.SU.EDU>
Sender: REM%IMSSS at SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-To: REM at MIT-MC.ARPA
To: RAM
Re: Query (FILE-LENGTH in particular) of file by name when open
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Mar-20 14:51:03 PST (=GMT-8hr)
> Date: Wed, 20 Mar 1985 04:31 EST
> From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
> Subject: Length of currently-open-for-write file is ambiguous or meaningless
>
> The meaning of File-Length on the name of a file which is open for
> write seems operating system dependant, and should be undefined. Since
> it is in fact this case which I understand to be the basis for not
> allowing file-length on file names, taking this stand would dispose of
> any problems.
May I take it that you mostly agree with me on this point, that the
ambiguity I pointed out (size of file before during or after current
update), and you're saying the default (or only possible
implementation) should be to signal an error if the file you happen to
ask about by name is currently open for write? (Therefore the general
idea of asking about a file by name is well-defined and should be
provided by CL: if the file is open-for-write the query signals an
error, else the query works as expected?)
If so, I think we've reached 2-party concensus (I yield on the other
point you made about query on lisp I/O-channel-object being meaningful).
∂20-Mar-85 2052 RAM@CMU-CS-C.ARPA [REM: destructive operations on circular emulation of infinite list]
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 20:52:01 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 20 Mar 85 23:21:34-EST
Date: Wed, 20 Mar 1985 21:25 EST
Message-ID: <RAM.12096661390.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: [REM: destructive operations on circular emulation of infinite list]
Date: 1985 March 20 03:01:16 PST (=GMT-8hr)
From: Robert Elton Maas <REM at IMSSS.SU.EDU>
Sender: REM%IMSSS at SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-To: REM at MIT-MC.ARPA
To: RAM
cc: "cork%umass-cs.csnet" at CSNET-RELAY.ARPA
Re: destructive operations on circular emulation of infinite list
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Mar-20 14:51:18 PST (=GMT-8hr)
> Date: Wed, 20 Mar 1985 05:07 EST
> From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
> Subject: Implementation of MAP, SOME, EVERY, etc...
>
> I think that a sufficiently fascist interpretation of the CLM
> would say that this is erroneous. Nowhere in the CLM is it stated
> that a circular list is the same as an infinite list, and it is
> unlikely that any implementation would consistently have those
> semantics. Setting element 537 of an infinite list should only
> change element 537. Setting element 537 in a one-element circular
> list would probably change all the elements if it terminates.
I agree. Mathematically if LISP emulates an infinite list by a
circular list instead of by a continuation, and you ask LISP to make
an infinite list, then if you ask LISP to change a single element, the
circular list must be converted to a linear list up to the point of
change so that only the single element you specify will get changed. A
problem arises however if you fake out LISP by doing a RPLACD or NCONC
et al yourself without telling LISP whether you really meant to end
upwith a circular list (side-effects shared) or an emulation of an
infinite lisp (unfold-on-modify). In that case CLM should say the
result is implementation-dependent and such trick should be avoided in
portable code. Rebuttal?
> The definition of a normal list in the Lists chapter is one
> terminated by NIL. By this definition, a circular list is a dotted
> list.
Does it say anything except a normal list is a dotted list? There are
no other datatypes in the world? Or does it allow a third choice
(infinite list, circular list, list-by-continuation, etc.) which it
then fails to properly document?
> I believe that there was a decision at one point that functions
> which use lists as sequences (a superset of the sequence functions)
> are allowed to complain about dotted lists.
I think they should complain about (finite) dotted lists, but permit
both normal lists and circular/infinite lists if the latter is/are
permitted otherwise in CL. The semantics of MAPping down a set of
lists none of which is normal nor dotted, should be that the process
runs forever until a THROW-type event happens or the environment runs
out of memory or another kind of error happens. For example, a
reasonable hack would be to MAP down a circular list of ten elements
and when a realtime interupt happens process the current cell and THROW
out of the otherwise-infinite loop, thereby processing a random element
from a finite set. Or MAP down a circular list of devices trying to
find one that is available, looping forever if none of them ever
become free, otherwise using the first random one that becomes free.
The code for looping in a circular list seems to me cleaner than using
a 2-level loop with the outer loop DOing FOREVER the inner finite loop.
If the manual is unclear, I favor the above. If the manual clearly
forbids my interpretation, then I guess it's too late to change it.
∂20-Mar-85 2122 JLW Implementation of MAP, SOME, etc
To: common-lisp@SU-AI.ARPA
Surely the CLM doesn't suggest that the implementation of these functions
must call the LENGTH function -- whereas it may not hurt to do so for what
I'd call "index access" datatypes, there are many reasons for not doing so
on lists. The phrase I see in the manual is "... if the end of a sequence
is reached ...", and this doesn't say how one determines that the end
is reached. But the docmentation of ENDP suggests that it is the preferred
way to answer the question for lists.
-- JonL --
∂20-Mar-85 2152 Gall.HIS←Guest@MIT-MULTICS.ARPA Follow-up and New Questions
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 21:52:19 PST
Posted-Date: 21 Mar 85 00:52 EST
Acknowledge-To: Nick Gall <Gall@MIT-MULTICS.ARPA>
Date: Thu, 21 Mar 85 00:49 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: Follow-up and New Questions
To: common-lisp@SU-AI.ARPA
cc: RAM@CMU-CS-C.ARPA, REM@MIT-MC.ARPA
Message-ID: <850321054958.626398@MIT-MULTICS.ARPA>
**********
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:Gall@MIT-MULTICS.ARPA
Subject:Compiler warning msgs
> !section 5.3.2(7) Nick Gall 85-03-19
> !version Digital Press 1984
> !topic Lexical variable with the same name as a named constant
> ... (illegal, can't do it)
> If this is the case, when would the compiler ever have the
> opportunity to
> ...issue warnings about bindings of the lexical variable of
> the same name [as a name declared by DEFCONSTANT to be
> constant].
My guess is what is meant by "warning" is "nonfatal diagnostic
message", i.e. the construction is illegal and the compiler can't
possibly compile it into correct code, but the error doesn't crash the
compiler, the compiler merely issues a diagnostic (warning) and
proceeds to try to recover and compile the rest of the file.
I think you misunderstood my question. Take this code for example:
(defconstant const ...)
(defun foo ()
(let ((const 1))
...))
One might think that the LET is binding a lexical variable named CONST; it is
not. LET is binding a special var. named CONST. This is due to the fact that
defconstant does an implicit proclaim. This proclaim pervasively affects all
bindings of the proclaimed var. This means that once a variable name appears
in a defconstant, there is no context in which the interpreter or compiler
would consider that name to be the name of a lexical variable. So... there is
no way the compiler could ever warn the user that they are using a lexical
variable with the same name as a constant. To put it briefly, I bet you can't
show me a piece of Common Lisp code that would cause such a warning.
**********
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:common-lisp@SU-AI.ARPA
CC:Gall@MIT-MULTICS.ARPA
Subject: What should CLOSE return? Closed-channel-object, or truefilename.
> !section 21.3(7) Nick Gall 85-03-19
> !version Digital Press 1984
> !topic What does CLOSE Return?
>
> I think it should return the STREAM it was given to close. This
> would make it symmetric with OPEN: OPEN returns an open stream,
> CLOSE returns a closed stream.
That's not symmetric, that's coercive. OPEN and CLOSE are like
matching parenthesis, one does it and the other undos it except for
a residual side-effect. OPEN takes a name and returns an I/O channel
(at the LISP level, an object that can be name an active stream of
data). CLOSE takes an I/O channel and should return a name to be
symmetric with OPEN. This would be an opportune time to solve race
conditions where several users are making different versions of the
same file at the same time by the trick of writing a temporary file
and then renaming it during the CLOSE. At CLOSE the version number is
determined, and at that moment before somebody can create a later
version the lisp CLOSE function obtains the true filename of the
particular version we created.
You're right `symmetric' is the wrong adj. But I still think CLOSE should
return the (closed) stream. It can't (always) return the truename of the file
associated with the stream, since not all streams are associated with files.
How can one rename a file `during' a CLOSE? CLOSE should not return until the
stream is really closed (and the file associated with the stream is quiesent).
To obtain the truename of a just closed file, one could write
(truename (close x)) ; where x is bound to a file stream
since truename will take a stream as an argument. (Unfortunately,
the CLRM (23.1.2(5)) is only explicit about what truename does
with an `open' stream.)
**********
From: Rob MacLachlan <RAM at CMU-CS-C>
Subject: Default attributes of copy due to SUBSEQ
To: REM at MIT-MC
cc: common-lisp at SU-AI, Gall at MIT-MULTICS
The semantics that I favor (and those implemented by Spice Lisp)
are that every Common Lisp function which returns an array returns a
simple array unless the function is make-array or one of the arguments
is eq to the result. This has the advantage of being a simple
specification, and also allows the compiler to do more interesting
type-inference.
Your semantics are correct:
Whenever a sequence function must construct and return a
new vector, it always returns a SIMPLE vector (see
section 2.5). Similarly, any strings will be simple
strings.
CLRM 14.0(last paragraph)
Sorry I didn't see this sooner...
**********
!section 11.7 Nick Gall 85-03-20
!version Digital Press 1984
!topic INTERN's effect on an accessible symbol's owner.
As a verb, to `intern' a symbol in a package means to
cause the symbol to be interned (sic) in the package if
it was not already; this function is performed by the
function INTERN. If the symbol was previously unowned,
then the package it is being interned in becomes its
owner (home package)...
CLRM Section 11.0 (pg. 172)
I interpret this passage in the following way:
;; Current package is USER
* (setf p1 (make-package 'p1 :use '()))
{printed rep. of p1}
* (import 'p1::xyzzy)
T
* (symbol-package 'xyzzy)
{printed rep. of p1}
* (unintern 'xyzzy p1)
T
* (symbol-package 'xyzzy)
NIL
* (intern "XYZZY")
XYZZY
:INTERNAL
* (symbol-package 'xyzzy)
{printed rep. of user}
In other words, INTERN ensures that the symbol that it returns
as its first value has a home package.
Is this interpretation correct?
------------------------------------------------------------
!section 11.7 Nick Gall 85-03-20
!version Digital Press 1984
!topic UNINTERNing a shadowing-symbol
UNINTERN:
When uninterning a shadowing symbol (call it foo), UNINTERN
collects all inherited symbols with the same print-name
as foo, including foo (assuming foo was inherited). If the name
conflict is only between foo and one other symbol, what sense
does it make to signal a name conflict error and give the user a
choice between shadow-importing foo and the other symbol. If the
user chooses foo, it is no different from aborting from the
error.
In the above case, shouldn't UNINTERN just automatically
shadow-import the other symbol?
------------------------------------------------------------
∂21-Mar-85 0056 RAM@CMU-CS-C.ARPA Implementation of MAP, SOME, EVERY, etc...
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Mar 85 00:56:48 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 21 Mar 85 03:56:22-EST
Date: Thu, 21 Mar 1985 03:56 EST
Message-ID: <RAM.12096732510.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Dave Dyer <DDYER@USC-ISIB.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Implementation of MAP, SOME, EVERY, etc...
In-reply-to: Msg of 20 Mar 1985 23:07-EST from Dave Dyer <DDYER at USC-ISIB.ARPA>
Our implementation of Map takes the length of every sequence; it
is a page of code. When every sequence is a list, things are simple.
Life is interesting when mapping over a list, a bit-vector and a
string.
Rob
∂21-Mar-85 0111 RAM@CMU-CS-C.ARPA Follow-up and New Questions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Mar 85 01:11:02 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 21 Mar 85 04:04:35-EST
Date: Thu, 21 Mar 1985 04:04 EST
Message-ID: <RAM.12096734006.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Nick Gall <Gall@MIT-MULTICS.ARPA>
Cc: common-lisp@SU-AI.ARPA, REM@MIT-MC.ARPA
Subject: Follow-up and New Questions
In-reply-to: Msg of 21 Mar 1985 00:49-EST from Nick Gall <Gall at MIT-MULTICS.ARPA>
From: Nick Gall <Gall at MIT-MULTICS.ARPA>
To: common-lisp at SU-AI.ARPA
Re: Follow-up and New Questions
Posted-Date: 21 Mar 85 00:52 EST
So... there is no way the compiler could ever warn the user that
they are using a lexical variable with the same name as a constant.
To put it briefly, I bet you can't show me a piece of Common Lisp code
that would cause such a warning.
The Spice Lisp compiler would object. Similarity between special
variables and constants is an implementation detail. The name names a
constant, the compiler knows this, the compiler complains.
Rob
∂21-Mar-85 1302 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: Follow-up and New Questions
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 21 Mar 85 13:02:16 PST
Date: Thu, 21 Mar 85 15:57 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: Re: Follow-up and New Questions
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 21 Mar 85 04:04 EST from "Rob MacLachlan"
Message-ID: <850321205739.178211@MIT-MULTICS.ARPA>
Given a piece of code like
(defconstant const ...)
(defun foo ()
(let ((const 1))
...))
I am not saying that the compiler would not object. I am saying that
WHEN it objected, the message MUST NOT be
Warning: Binding a LEXICAL variable with the same name as
a constant.
it SHOULD be
Error: Attempting to bind a SPECIAL variable defined by
DEFCONSTANT.
It can't be the first message, because DEFCONSTANT, by doing an implicit
(proclaim '(special const))
(which pervasively affect BINDINGS and references) FORCES the compiler
to assume that the LET form is binding a SPECIAL variable, not a LEXICAL
variable. To put it briefly, I was merely arguing that the variable
name `const' in the LET form could not possibly considered a LEXICAL
variable (so how could the compiler warn me about a `lexical'
variable?).
-- Nick
∂21-Mar-85 1317 FAHLMAN@CMU-CS-C.ARPA Follow-up and New Questions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Mar 85 13:16:47 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 21 Mar 85 16:15:50-EST
Date: Thu, 21 Mar 1985 16:15 EST
Message-ID: <FAHLMAN.12096867089.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Nick Gall <Gall@MIT-MULTICS.ARPA>
Cc: common-lisp@SU-AI.ARPA, Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Subject: Follow-up and New Questions
In-reply-to: Msg of 21 Mar 1985 15:57-EST from Nick Gall <Gall at MIT-MULTICS.ARPA>
Let's just issue the warning "Attempting to bind a constant, FOO, as a
variable" and let it go at that. No point in arguing about what kind of
variable it would be if this illegal operation weren't illegal.
-- Scott
∂21-Mar-85 1352 Gall.HIS←Guest@MIT-MULTICS.ARPA Lost bet
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 21 Mar 85 13:52:41 PST
Date: Thu, 21 Mar 85 16:49 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: Lost bet
To: common-lisp@SU-AI.ARPA
Message-ID: <850321214921.734669@MIT-MULTICS.ARPA>
(defun foo ()
(let ((const 1)) const))
(defconstant const 2) ;; Compiler should issue a warning about
;; the use of lexical variable const in
;; foo.
(defun bar ()
(let ((const 2)) const) ;; Compiler should signal an
;; error about the binding of a
;; constant.
I guess I lose my bet.
-- Nick
∂21-Mar-85 2218 cork%umass-cs.csnet@csnet-relay.arpa More on MAP, SOME, EVERY, etc.....
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 21 Mar 85 22:18:39 PST
Received: from umass-cs by csnet-relay.csnet id ag24346; 22 Mar 85 1:07 EST
Date: Thu, 21 Mar 85 13:21 EST
From: Dan Corkill <cork%umass-cs.csnet@csnet-relay.arpa>
To: common-lisp@su-ai.ARPA
Subject: More on MAP, SOME, EVERY, etc.....
As I expected, my flame about MAP, SOME, EVERY, etc. has raised some
important issues.....
First, RAM suggests that viewing a circular list as a dotted list
avoids the problem:
> The definition of a normal list in the Lists chapter is one
> terminated by NIL. By this definition, a circular list is a dotted
> list. I believe that there was a decision at one point that functions
> which use lists as sequences (a superset of the sequence functions)
> are allowed to complain about dotted lists. This is implied by the
> statement that Endp is the canonical list-end predicate.
However, the next sentence from that chapter argues that a circular
list CANNOT be a dotted list:
``A list whose cdr chain is terminated by some non-nil atom is called
a dotted list.'' Clearly, a circular list is not terminated by some
non-NIL atom (is it terminated at all?), and ENDP cannot be used to
detect a circular list.
~~ An aside --- As the CLM is unclear on whether or not a circular is
~~ is an ORDINARY or DOTTED list, I would argue that it is better
~~ viewed as an ORDINARY list. In a sense a circular list is a list
~~ that shares structure with itself. Unless destructive functions
~~ are applied to a circular list, it behaves identically to an
~~ infinite list. Further supporting this position is the observation
~~ that mapc, mapcar, etc. work with circular list arguments and
~~ generate errors with dotted (non-circular) list arguments.
*** Back to the original complaint about MAP, SOME, EVERY, etc. ***
Under the premise that a circular list is NOT a dotted list, the
implementation of MAP, SOME, EVERY, etc. should not care whether
or not an argument sequence is circular or not. (It should be
up to the user to worry about the effects of any destructive
changes to an arglist. I suggest that all the following should
be legal:
(map 'list '+ '(1 2 3) (star 5)) => (6 7 8)
;; (defun star (&REST arglist)
;; (nconc arglist arglist))
(some 'char< "string" (star #\x)) => t
(map 'array '#(2 3 4) (star 5)) => #(7 8 9)
(replace '(1 2 3 4 5) (star -1)
:START1 2 :END1 4)) => (1 2 -1 -1 5)
;; Note that (replace (star -1) '(1 2 3 4 5) :start1 2 :end1 4)
;; should not be expected to produce (-1 -1 1 2 -1 ... ). But
;; should be undefined as to what it does.
I agree with Dave Dyer that the programmer shouldn't have to know anything
about the lists passed to MAPxxx except that the shortest sequence (if a
list) is a proper list.
I would hope that even the following would be legal:
(map 'list '+ '(1 2 3) '(1 2 3 4 5 . 6)) => (2 4 6)
I also agree that the use of LENGTH for lists is a poor implementation
technique, and Dave's admonition against the use of LENGTH in system
functions unless all elements are guaranteed to be inspected is
reasonable.
In summary, I believe that implementations of MAP, SOME, EVERY, etc.
using LENGTH do not follow the semantics of the CLM and are inconsistent
with the usual behavior of the traditional list mapping functions.
I strongly suggest that it is the implementations that are incorrect
rather than ambiguity in the semantics and argue that merely changing
the descriptions to explicitly exclude circular lists greatly curtails
the utility of the sequence functions.
Dan Corkill
Cork@UMass
∂25-Mar-85 1831 JLW DELFILE, thanks to DWIM
To: DHare@SRI-CSL.ARPA
CC: Common-Lisp@SU-AI.ARPA
Apart from the failure to ask if you wanted the "correction" GETFILE into
DELFILE, there is also the question of why DELFILE was happy with the
extra argument (in your example, 'SIZE). Common Lisp programs have the
notion of argument-number checking, and many spurious forms like
(DELFILE 'FOO.BAR 'SIZE) would be rejected at that level.
Argument-number checking isn't completely incompatible with Interlisp --
or at least the use of Interlisp without unwarranted DWIM interference.
All that would be required is the breaking of the rather dubious contract
that *all* functions must have *all* arguments in the category of "optional
and defaulting to NIL".
Totaly leaving aside the question of backwards compatibility with all those
never-changing Interlisp programs dating back to the 1960's, it would be
instructive to know what percentage of current users feel that the current
situation of *no* argment-number checking is completely satisfactory. The
alternative need not require explicity NIL's in calling code, since many
functions may want some kind of &optional behaviour anyway.
-- JonL --
∂25-Mar-85 1914 JLW Excluding some symbols from DO-ALL-SYMBOLS
To: Hedrick@RUTGERS.ARPA
CC: Common-Lisp@SU-AI.ARPA
Re your message of 4-Mar-85 19:05 EST
I'm a little bit apprehensive about having two "functions" to iterater over
"all the symbols of interest" -- How about instead of introducing the second
one [do-most-symbols] we simply introduce a new global variable called, say,
*do-all-symbols-exclusions*
This list would merely exclude some of the packages which would otherwise
be the output of list-all-packages. This way, not only could the compiler
internal symbols be omitted, but any other package which a user develops
could also be, temporarily or permanently, excluded. I'm currently thinking
that this facility would not exclude the external symbols of those packages.
-- JonL --
∂26-Mar-85 0312 JLW Previous note about DELFILE/DWIM
To: common-lisp@SU-AI.ARPA
My apologies for this note getting onto the mailing list -- it was not
intended for Common Lisp, but rather for Bug-1100. The spazz was partly
my fault, and partly a "gift" from the wonderful featurfulness of the
su-ai editor/mailer.
-- JonL --
∂27-Mar-85 1240 eak@angband multiple-value-setq
Received: from S1-B.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 12:40:51 PST
Received: by angband.ARPA id AA00677; Wed, 27 Mar 85 11:14:11 pst
id AA00677; Wed, 27 Mar 85 11:14:11 pst
Date: Wed, 27 Mar 85 11:14:11 pst
From: Earl Killian <eak@angband>
Message-Id: <8503271914.AA00677@angband.ARPA>
To: common-lisp@su-ai.ARPA
Subject: multiple-value-setq
Is this really multiple-value-setf? I.e. can the list be a list of
places or just a list of variables?
∂27-Mar-85 1241 eak@angband values-list
Received: from S1-B.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 12:41:03 PST
Received: by angband.ARPA id AA00664; Wed, 27 Mar 85 11:10:55 pst
id AA00664; Wed, 27 Mar 85 11:10:55 pst
Date: Wed, 27 Mar 85 11:10:55 pst
From: Earl Killian <eak@angband>
Message-Id: <8503271910.AA00664@angband.ARPA>
To: common-lisp@su-ai.ARPA
Subject: values-list
A useful extension to values-list would be to make it take multiple
arguments the way apply does, i.e. all but the last are values to
return and the last is a list of further values to return.
∂27-Mar-85 1807 Moon@SCRC-STONY-BROOK.ARPA do-xxx-symbols
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 13:35:07 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204359; Wed 27-Mar-85 16:05:30-EST
Date: Wed, 27 Mar 85 16:06 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: do-xxx-symbols
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>,
Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>,
Charles Hedrick <HEDRICK@RUTGERS.ARPA>
cc: common-lisp@SU-AI.ARPA, Moon@SCRC-STONY-BROOK.ARPA
In-Reply-To: <RAM.12092370210.BABYL@CMU-CS-C.ARPA>,
<FAHLMAN.12092383554.BABYL@CMU-CS-C.ARPA>,
The message of 4 Mar 85 19:05-EST from Charles Hedrick <HEDRICK@RUTGERS.ARPA>,
The message of 4 Mar 85 21:50-EST from Charles Hedrick <HEDRICK@RUTGERS.ARPA>,
<FAHLMAN.12092488741.BABYL@CMU-CS-C.ARPA>,
The message of 4 Mar 85 23:34-EST from Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Message-ID: <850327160624.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comment: Message remailed after delay caused by distribution list error.
Due to some kind of mail problem I didn't see this conversation until today.
We take DO-SYMBOLS to mean to iterate over all symbols accessible to this package,
including ones that are inherited from other packages. That seems like the most
reasonable interpretation of what the manual says. I agree with Scott that the authors
of the manual never imagined that other interpretations were possible.
We provide DO-LOCAL-SYMBOLS as an extension. It iterates over only symbols present
in the specified package.
Our DO-SYMBOLS has the usual bug with shadowed symbols: its iteration includes symbols
that would have been inherited had they not been shadowed. I think it's clear that
this is a bug and not an allowable interpretation of the manual.
Our DO-SYMBOLS has the usual bug with unnecessarily imported or exported
symbols: its iteration sees a symbol more than once if that symbol is imported
even though it would have been inherited, or is exported from two used packages.
Perhaps this case is rare enough in practice, and difficult enough to test for,
that the manual should be changed to say that a symbol can be seen more than once,
as Scott suggested.
Of course, certain implementations of packages (ones that hash symbols
redundantly in every package that inherits them, so that INTERN need do only
a single hash lookup regardless of the length of the use-list) would never
encounter such bugs. Perhaps the language should be based on such a simple
implementation as a standard, and other implementations that try to save
space are responsible for not deviating from that standard. Opinions?
∂27-Mar-85 1808 Moon@SCRC-STONY-BROOK.ARPA Implementation of MAP, SOME, EVERY, etc...
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 13:39:50 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204367; Wed 27-Mar-85 16:16:13-EST
Date: Wed, 27 Mar 85 16:17 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Implementation of MAP, SOME, EVERY, etc...
To: Dan Corkill <cork%umass-cs.csnet@CSNET-RELAY.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 19 Mar 85 11:58-EST from Dan Corkill <cork%umass-cs.csnet@csnet-relay.arpa>
Message-ID: <850327161712.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comment: Message remailed after delay caused by distribution list error.
Date: Tue, 19 Mar 85 11:58 EST
From: Dan Corkill <cork%umass-cs.csnet@csnet-relay.arpa>
There is an easily made implementation error in MAP, SOME, EVERY, etc.
The published semantics indicate that these functions use the length of
the shortest argument sequence to determine how many iterations to
perform (and in this way parallel the semantics of mapc, mapcar, etc.).
Thus it would appear that:
(map 'list '+ '(1 2 3) (star 2))
where star builds a circular list of its argument should be legal and
return => (3 4 5).
Implementations that use length to check the length of argument sequences
will break on such a call.
The Common Lisp LENGTH function returns NIL when given a circular list.
∂27-Mar-85 1818 FAHLMAN@CMU-CS-C.ARPA multiple-value-setq
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 16:40:16 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 27 Mar 85 19:39:45-EST
Date: Wed, 27 Mar 1985 19:39 EST
Message-ID: <FAHLMAN.12098477115.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Earl Killian <eak@S1-B.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: multiple-value-setq
In-reply-to: Msg of 27 Mar 1985 14:14-EST from Earl Killian <eak at angband>
Comment: Remailed after delay caused by distribution list error at SU-AI.
Is this really multiple-value-setf? I.e. can the list be a list of
places or just a list of variables?
Multiple-Value-Setq definitely does not take SETF-style place names. I
think that the manual is quite clear on this. Whether there should be
an M-V-SETF is another issue, but I don't think there's much demand for
this. I've seen very few uses of M-V-SETQ, as compared with M-V-BIND.
-- Scott
∂27-Mar-85 1820 FAHLMAN@CMU-CS-C.ARPA do-xxx-symbols
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 14:13:39 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 27 Mar 85 17:12:29-EST
Date: Wed, 27 Mar 1985 17:12 EST
Message-ID: <FAHLMAN.12098450245.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: do-xxx-symbols
In-reply-to: Msg of 27 Mar 1985 16:06-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Comment: Remailed after delay caused by distribution list error at SU-AI.
I thought that you had been unusually quiet of late.
Of course, certain implementations of packages (ones that hash symbols
redundantly in every package that inherits them, so that INTERN need do only
a single hash lookup regardless of the length of the use-list) would never
encounter such bugs. Perhaps the language should be based on such a simple
implementation as a standard, and other implementations that try to save
space are responsible for not deviating from that standard. Opinions?
I think that requiring adherence to a model that is conceptually simple
but that imposes a very heavy (and in my opinion, unacceptable) cost in
space is the wrong move here, unless you can demonstrate some reasonable
way of adhering to that model without incurring these costs. To just
asy "it's the implementor's problem" is a good way to either make the
language unusable because of the adherence to impractical models or to
get the implementors to decide to deviate from the standard rather than
pay these costs.
Yes, I know we've done it before in this language, but in a couple of
cases we've come to regret it.
-- Scott
∂27-Mar-85 1820 FAHLMAN@CMU-CS-C.ARPA values-list
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 16:51:22 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 27 Mar 85 19:50:43-EST
Date: Wed, 27 Mar 1985 19:50 EST
Message-ID: <FAHLMAN.12098479109.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Earl Killian <eak@S1-B.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: values-list
In-reply-to: Msg of 27 Mar 1985 14:10-EST from Earl Killian <eak at angband>
Comment: Remailed after delay caused by distribution list error at SU-AI.
A useful extension to values-list would be to make it take multiple
arguments the way apply does, i.e. all but the last are values to
return and the last is a list of further values to return.
You can easily get the effect you want with a macro, as long as you're
willing to cons all the returned values into a list at some point. I
guess your point is that sometimes you don't know how many values to
expect, but would like to handle the first few without consing via
values-list. Multiple-Value-Call with a &rest arg gives you this
effect, but forces you to do a function call that might be superfluous.
So there is a niche for your proposed mechanism, but I don't think it's
a common enough situation to worry about. The only cases I've seen
where you don't know how many args are coming back would not be bothered
by the overhead of the function call or the values-list; in the tense
cases, you generally how many args to expect.
-- Scott
∂27-Mar-85 2020 FAHLMAN@CMU-CS-C.ARPA Implementation of MAP, SOME, EVERY, etc...
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 20:20:08 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 27 Mar 85 23:19:20-EST
Date: Wed, 27 Mar 1985 23:19 EST
Message-ID: <FAHLMAN.12098517085.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Implementation of MAP, SOME, EVERY, etc...
In-reply-to: Msg of 27 Mar 1985 16:17-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Moon claims:
The Common Lisp LENGTH function returns NIL when given a circular list.
I disagree. On page 265 of the aluminum edition, we find the following
quote:
"LIST-LENGTH differs from LENGTH when the list is circular; LENGTH may
fail to return, whereas LIST-LENGTH will return NIL."
The feeling was that LENGTH was used often, and we didn't want to
require that it run more slowly on all lists just to accommodate the
rare case of a circular list.
-- Scott
∂28-Mar-85 0553 Moon@SCRC-STONY-BROOK.ARPA [Gall: Bug Report]
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 05:52:50 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204544; Wed 27-Mar-85 20:08:58-EST
Date: Wed, 27 Mar 85 20:09 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: [Gall: Bug Report]
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12096404394.BABYL@CMU-CS-C.ARPA>,
The message of 19 Mar 85 21:53-EST from Fahlman at CMU-CS-C,
<FAHLMAN.12096404394.BABYL@CMU-CS-C.ARPA>,
The message of 21 Mar 85 00:49-EST from Gall@MIT-MULTICS.ARPA,
<850321054958.626398@MIT-MULTICS.ARPA>
Message-ID: <850327200955.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Here are some comments on -portions- of the two long messages from Nick Gall.
!section 9.1(6) Nick Gall 85-03-19
!version Digital Press 1984
!topic Pervasiveness of declarations over FLET and LABELS
Example:
(defun the-many-function-names-foo (x)
(declare (inline foo))
(foo x) ; First call of FOO
(flet ((foo (y z) (zap z y)))
(foo x x)) ; Second call of FOO
(foo x)) ; Third call of FOO
....
Declarations concerning function names should be treated as
special variable declarartions are: references are pervasively
affected, but not bindings.
Agreed. There are a number of areas in the language where the
implications of adding FLET and LABELS (thus adding local function
definitions) were not immediately obvious and therefore were not
reflected in other parts of the manual.
!section 9.1(12) Nick Gall 85-03-19
!version Digital Press 1984
!topic Non-Top-Level use of PROCLAIM
Can PROCLAIM be used, other than at top-level? Since DEFVAR,
etc., are proclamations and can be used at other than top-level,
the answer to this question seems to be `yes'.
Agreed.
Is PROCLAIM a `declaration', i.e., must it appear only where a
declaration is allowed? Since it is allowed at top-level (unlike
DECLARE), and it is a function, and since the other proclaiming
forms (e.g. DEFVAR, etc.) could not be considered declarations
(since they perform evaluation and assignment), the answer must
be no.
Agreed.
Then what is the effect of using PROCLAIM (or one one the other
proclaiming forms) in the middle of a function? For example:
(defun foo (a) (zap a) (proclaim '(special a)) (zark a))
Does the first reference to A refer to the local binding? Does
the second reference refer to the global?
PROCLAIM is merely a function, and has effect when it is called, not
when a call to it is compiled. Your example might be rewritten as
(defun foo (a)
(zap a)
(eval-when (compile)
(proclaim '(special a)))
(zark a))
were EVAL-WHEN permitted inside a function body (it is not; see p.66).
Of course you could write a macro that evaluates the PROCLAIM at macro
expansion time. If you did so, you could properly be castigated for
using incomprehensible programming style, and I presume your program
would execute differently in different Common Lisp compilers and
interpreters.
Some mention of the effects of the non-top-level use of PROCLAIM
and the other proclaiming forms should be made.
On p.66 it says that DEFVAR is not allowed elsewhere than top-level.
PROCLAIM is the only function (rather than special form) that makes
declarations, and presumably the declarations it makes when it is
called take effect "immediately", but the exact definition of "immediately"
might be implementation-dependent. For example, it is implementation-
dependent whether PROCLAIM affects interpreted functions that have already
been defined.
-----------------------------------------------------------------
!section 7.5(14) Nick Gall 85-03-19
!version Digital Press 1984
!topic Scope and Extent of local function names
NOTE: See 9.2 (ftype, function, inline).
Example:
(DEFUN CREATE-MAKEP (MAKE)
(FLET ((CAR (SYMBOL) (GET SYMBOL 'AUTOMOBILE)))
#'(LAMBDA (OWNER) (EQ MAKE (CAR OWNER)))))
(SETQ FOO (CREATE-MAKEP 'HONDA))
(FUNCALL FOO 'BILL) => ?????
Question: What does CAR refer to when it is used in the closure
returned by CREATE-MAKEP? I.E., What is the scope and
extent of the binding of a local function name to a
functional object?
Section 7.1(1) states that "There are two spaces of variables in
Common Lisp, in effect: ordinary variables and function names."
And the function name binding control structures appear in the
section entitled "Establishing New Variable Bindings".
Lexical function name bindings and lexical variable name bindings are
treated identically. This should, of course, be discussed in chapter 3.
See above comment about the implications of FLET and LABELS not having
been fully thought out and reflected in the manual.
I suggest that Common Lisp go all the way, and allow a
SPECIAL-FUNCTION-NAME declaration that would be analogous to the
SPECIAL declaration for "ordinary" variables.
Such a concept would make the idea of
ordinary-variable/function-name binding and assignment much more
consistent.
As I recall this was considered and rejected on the basis that it would
be confusing and wouldn't give any real increase in expressive power
(since FUNCALL of a special variable could be used). I agree with that
decision, even though our implementation has always had the feature.
The only place where we use it is in a crock that could just as well be
done some other way.
-----------------------------------------------------------------
!section 10.3(9) Nick Gall 85-03-19
!version Digital Press 1984
!topic Which bindings are copied by COPY-SYMBOL?
"the initial value and function-definition of the new symbol
will be the same as those of SYM..."
Does this mean that the (dynamic) value of the variable
referred to by SYM, at the point where COPY-SYMBOL symbol is
invoked, is copied? Or, does it mean that the `initial', i.e.
global value of the special variable named by SYM is copied?
Although the wording seems to suggest the latter, it should be
made clearer.
The word "initial" was meant to refer to the new symbol, not the old
symbol, I believe. Probably no one realized the English could be
regarded as ambiguous.
The same questions and suggestion applies to the
function-definition copied by COPY-SYMBOL.
-----------------------------------------------------------------
!section 15.5(8) Nick Gall 85-03-19
!version Digital Press 1984
!topic Is (TAILP NIL list) true or false for every list?
False.
By the way, the index entry for TAILP contains a typographical error and
furthermore the function is documented in the wrong section (it's hard
to see a justification for regarding it as an operation on sets).
"...TAILP is true if (NTHCDR n list) is sublist, for some value
of N." According to this definition NIL is a sublist of every
list, since the (NTHCDR (LENGTH list) list) is NIL for every
LIST.
Yes, this side comment in the text would better have been omitted.
-----------------------------------------------------------------
!section 20.1(7) Nick Gall 85-03-19
!version Digital Press 1984
!topic Is *APPLYHOOK* funcalled for special forms?
"The variable *APPLYHOOK* ... is used when a function is about to
be applied to arguments." Does `function' refer to a functional
object which is in fact a function (i.e., its args. are evaled
before it is called), or does it refer to any functional object
(e.g., `special' functional objects)?
Special forms are excluded.
Later in the paragraph, it is stated that,
The apply hook function is used only for application of
ordinary functions within eval. It is not used for
applications via apply, or funcall, for applications by such
functions as map or reduce, or for invocation of
macro-expansion functions...
This paragraph does not really address the "application of
ordinary functions within eval" but rather the "ordinary
application of functions by eval."
I disagree (but this may be an ambiguity of English).
Also it does not clarify the
action taken for special forms.
Indeed, it ought to say something like "linkage from EVAL to special forms."
Part of the problem is that there is no way, in Common Lisp, to describe
the intercommunication between EVAL and special forms, since it is
implementation-dependent and the language provides no way for the user
to add new special forms. This is not a deficiency in the language (in
my opinion), just something that makes it hard to fit special forms into
that paragraph of documentation.
-----------------------------------------------------------------
!section 20.1(last-1) Nick Gall 85-03-19
!version Digital Press 1984
!topic Is nil declared by defconstant?
...all constant symbols declared by DEFCONSTANT, such as NIL,
T, and PI.
If NIL is declared by DEFCONSTANT then it can legally be
redefined according to section 5.1.2(last):
Constant symbols defined by DEFCONSTANT ... may be redefined,
if necessary, by using DEFCONSTANT again[].
Is such an interpretation correct?
I do not believe that system-supplied constants can legally be redefined.
-----------------------------------------------------------------
!section 4.8(1) Nick Gall 85-03-19
!version Digital Press 1984
!topic The meaning of the word `convert'
Does coerce `convert' (i.e., change the type bits) and return the
original object (or the pointer if typed pointers are supported)
when possible (e.g., coercing a string to an array of
(unsigned-byte 8) in some implementations); or does coerce ALWAYS
create and return a new `equivalent' object; or does the Common
Lisp spec. not define this?
Common Lisp does not specify sharing or non-sharing of storage between
the argument and result of COERCE. I don't see how it could, since this
is necessarily very implementation-dependent. But the documentation
could be clearer.
!section 11.7 Nick Gall 85-03-20
!version Digital Press 1984
!topic INTERN's effect on an accessible symbol's owner.
As a verb, to `intern' a symbol in a package means to
cause the symbol to be interned (sic) in the package if
it was not already; this function is performed by the
function INTERN. If the symbol was previously unowned,
then the package it is being interned in becomes its
owner (home package)...
CLRM Section 11.0 (pg. 172)
I interpret this passage in the following way:
;; Current package is USER
* (setf p1 (make-package 'p1 :use '()))
{printed rep. of p1}
* (import 'p1::xyzzy)
T
* (symbol-package 'xyzzy)
{printed rep. of p1}
* (unintern 'xyzzy p1)
T
* (symbol-package 'xyzzy)
NIL
* (intern "XYZZY")
XYZZY
:INTERNAL
* (symbol-package 'xyzzy)
{printed rep. of user}
In other words, INTERN ensures that the symbol that it returns
as its first value has a home package.
Is this interpretation correct?
I think the mention of accessible but unowned symbols on page 172 (in the
discussion of home packages) shoots down your example. The result of the
last call to SYMBOL-PACKAGE is probably undefined.
------------------------------------------------------------
!section 11.7 Nick Gall 85-03-20
!version Digital Press 1984
!topic UNINTERNing a shadowing-symbol
UNINTERN:
When uninterning a shadowing symbol (call it foo), UNINTERN
collects all inherited symbols with the same print-name
as foo, including foo (assuming foo was inherited). If the name
conflict is only between foo and one other symbol, what sense
does it make to signal a name conflict error and give the user a
choice between shadow-importing foo and the other symbol. If the
user chooses foo, it is no different from aborting from the
error.
In the above case, shouldn't UNINTERN just automatically
shadow-import the other symbol?
Surely it is a bad idea to guess the user's intent in this pathological
case, rather than asking. I suppose it would be legal for a debugger
not to offer the redundant option of shadowing-importing foo again,
although that doesn't seem like a feature of great importance.
I hope someone is listening to comments on unclarities in the manual,
such as Gall's, and that someday a revised and improved manual will
be issued. The Common Lisp community is hardly in possession of the
same resources as the Ada community, so I don't think we can realistically
expect as precise a specification as Ada enjoys.
∂28-Mar-85 1036 Moon@SCRC-STONY-BROOK.ARPA Implementation of MAP, SOME, EVERY, etc...
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 10:35:58 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204967; Thu 28-Mar-85 13:18:36-EST
Date: Thu, 28 Mar 85 13:19 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Implementation of MAP, SOME, EVERY, etc...
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12098517085.BABYL@CMU-CS-C.ARPA>
Message-ID: <850328131955.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 27 Mar 1985 23:19 EST
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Moon claims:
The Common Lisp LENGTH function returns NIL when given a circular list.
I disagree. On page 265 of the aluminum edition, we find the following
quote:
"LIST-LENGTH differs from LENGTH when the list is circular; LENGTH may
fail to return, whereas LIST-LENGTH will return NIL."
The feeling was that LENGTH was used often, and we didn't want to
require that it run more slowly on all lists just to accommodate the
rare case of a circular list.
My mistake. LENGTH used to check for circular lists, and when that feature
was removed from the language we saw no reason to remove it from our
implementation. I foolishly relied on memory and trying an example,
rather than checking the manual.
∂28-Mar-85 1116 FAHLMAN@CMU-CS-C.ARPA values-list
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 11:16:17 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 28 Mar 85 14:15:35-EST
Date: Thu, 28 Mar 1985 14:15 EST
Message-ID: <FAHLMAN.12098680245.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA, Earl Killian <eak@S1-B.ARPA>
Subject: values-list
In-reply-to: Msg of 28 Mar 1985 13:36-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Ooops, my reply was indeed about Multiple-Value-List. If EAK did indeed
mean that he wanted Values-List to take args like apply, I agree with
Moon that just using apply here solves the problem without adding any
extra hair to the language.
This week's confusion score stands at Moon 1, Fahlman 1. Look's like
we're headed for overtime to break the tie.
-- Scott
∂28-Mar-85 1126 Moon@SCRC-STONY-BROOK.ARPA values-list
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 11:26:13 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204994; Thu 28-Mar-85 13:35:14-EST
Date: Thu, 28 Mar 85 13:36 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: values-list
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: Earl Killian <eak@S1-B.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12098479109.BABYL@CMU-CS-C.ARPA>
Message-ID: <850328133629.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 27 Mar 1985 19:50 EST
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
From: EAK
A useful extension to values-list would be to make it take multiple
arguments the way apply does, i.e. all but the last are values to
return and the last is a list of further values to return.
What's wrong with (APPLY #'VALUES-LIST A B C L)?
You can easily get the effect you want with a macro, as long as you're
willing to cons all the returned values into a list at some point. I
guess your point is that sometimes you don't know how many values to
expect, but would like to handle the first few without consing via
values-list. Multiple-Value-Call with a &rest arg gives you this
effect, but forces you to do a function call that might be superfluous.
So there is a niche for your proposed mechanism, but I don't think it's
a common enough situation to worry about. The only cases I've seen
where you don't know how many args are coming back would not be bothered
by the overhead of the function call or the values-list; in the tense
cases, you generally how many args to expect.
This discussion appears to be about MULTIPLE-VALUE-LIST.
∂28-Mar-85 1154 EAK@MIT-MC values-list
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 11:51:48 PST
Date: 28 March 1985 14:52-EST
From: Earl A. Killian <EAK @ MIT-MC>
Subject: values-list
To: Moon @ SCRC-STONY-BROOK
cc: common-lisp @ SU-AI
Date: Thu, 28 Mar 85 13:36 EST
From: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
What's wrong with (APPLY #'VALUES-LIST A B C L)?
You mean (APPLY #'VALUES A B C L). This is actually where the
idea comes from.
I don't really care about this; I was just observing that an
obvious extension exists. If I wanted to be argumentative my
reply would be
"The same thing that's wrong with (APPLY #'VALUES L)
that caused (VALUES-LIST L) to be added to the language."
∂28-Mar-85 1158 RWK@SCRC-STONY-BROOK.ARPA Clearly non-controversial
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 11:58:17 PST
Received: from SCRC-CROW by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 205049; Thu 28-Mar-85 14:32:07-EST
Date: Thu, 28 Mar 85 14:32 EST
From: Robert W. Kerns <RWK@SCRC-STONY-BROOK.ARPA>
Subject: Clearly non-controversial
To: brown@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 6 Feb 85 12:52-EST from brown at DEC-HUDSON
Message-ID: <850328143248.2.RWK@CROW.SCRC.Symbolics.COM>
Date: Wed, 06 Feb 85 12:52:15 EST
From: brown@DEC-HUDSON
DELETE-SETF-METHOD access-fn [function]
Removes the update form associated with the symbol access-fn.
The access function can no longer be used as generalized
variable.
Either FMAKUNBOUND should call this, or maybe it should just
be a part of FMAKUNBOUND.
HASH-TABLE-REHASH-SIZE hash-table [function]
HASH-TABLE-REHASH-TRESHOLD hash-table [function]
Should these two be SETFable?
HASH-TABLE-SIZE hash-table [function]
HASH-TABLE-TEST hash-table [function]
These functions return the values that were specified when
the hash-table was created.
(This list used to contain TERMINALP which returned T if its
argument (string, pathname, etc.) was an "interactive terminal".
I think this function would be useful, but decided I was unable
to define what a terminal is, so removed it.)
How about "a terminal is something that has a keyboard attached,
with a good chance of having a user attached to the keyboard, and
able to send characters back on any stream"? I'd suggest just
defining it to work on streams.
-Gary Brown
∂28-Mar-85 1433 DLW@SCRC-STONY-BROOK.ARPA [Gall: Bug Report]
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 14:33:20 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 205213; Thu 28-Mar-85 16:54:47-EST
Date: Thu, 28 Mar 85 16:56 EST
From: Daniel L. Weinreb <DLW@SCRC-STONY-BROOK.ARPA>
Subject: [Gall: Bug Report]
To: Moon@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <850327200955.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <850328165608.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Wed, 27 Mar 85 20:09 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
were EVAL-WHEN permitted inside a function body (it is not; see p.66).
...
On p.66 it says that DEFVAR is not allowed elsewhere than top-level.
Are we reading the same page 66? Mine says "It is not illegal to use
these forms at other than top level, but whether it is meaningful to do
so depends on context." To my ears, this is sort of like saying
that integers can be of any precision, but after they get larger
than the fixnum limit, their behavior depends on context.
Also, note the wording in the description of DEFUN on page 67: "Because
DEFUN forms normally appear at top level, this is normally the null
lexical environment." This wording strongly suggests that DEFUN might
sometimes not be at top level, and the environment is not necessarily
always null. After all, if DEFUN were only allowed at top-level, why
bother with the "normally" qualifiers? But you never find out anything
further.
I'm not advocating either side right at the moment; my point is that the
manual is ambiguous (one might even say "coy") on this subject.
∂28-Mar-85 1434 Moon@SCRC-STONY-BROOK.ARPA values-list
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 14:34:38 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 205160; Thu 28-Mar-85 16:13:54-EST
Date: Thu, 28 Mar 85 16:15 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: values-list
To: Earl A. Killian <EAK@MIT-MC.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 28 Mar 85 14:52-EST from Earl A. Killian <EAK at MIT-MC>
Message-ID: <850328161516.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 28 March 1985 14:52-EST
From: Earl A. Killian <EAK @ MIT-MC>
Date: Thu, 28 Mar 85 13:36 EST
From: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
What's wrong with (APPLY #'VALUES-LIST A B C L)?
You mean (APPLY #'VALUES A B C L). This is actually where the
idea comes from.
You're right.
I don't really care about this; I was just observing that an
obvious extension exists. If I wanted to be argumentative my
reply would be
"The same thing that's wrong with (APPLY #'VALUES L)
that caused (VALUES-LIST L) to be added to the language."
Indeed, I wouldn't care to defend the presence of VALUES-LIST in the language.
∂28-Mar-85 1621 Moon@SCRC-STONY-BROOK.ARPA [Gall: Bug Report]
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 16:21:40 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 205314; Thu 28-Mar-85 19:04:52-EST
Date: Thu, 28 Mar 85 19:06 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: [Gall: Bug Report]
To: Daniel L. Weinreb <DLW@SCRC-STONY-BROOK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850328165608.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <850328190615.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 28 Mar 85 16:56 EST
From: Daniel L. Weinreb <DLW@SCRC-STONY-BROOK.ARPA>
Date: Wed, 27 Mar 85 20:09 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
were EVAL-WHEN permitted inside a function body (it is not; see p.66).
...
On p.66 it says that DEFVAR is not allowed elsewhere than top-level.
Are we reading the same page 66? Mine says "It is not illegal to use
these forms at other than top level, but whether it is meaningful to do
so depends on context." To my ears, this is sort of like saying
that integers can be of any precision, but after they get larger
than the fixnum limit, their behavior depends on context.
In my opinion, saying that is not meaningful is tantamount to saying that
it is not allowed. The phrase I should have used was not "not allowed",
but "not defined by standard Common Lisp".
Also, note the wording in the description of DEFUN on page 67: "Because
DEFUN forms normally appear at top level, this is normally the null
lexical environment." This wording strongly suggests that DEFUN might
sometimes not be at top level, and the environment is not necessarily
always null. After all, if DEFUN were only allowed at top-level, why
bother with the "normally" qualifiers? But you never find out anything
further.
I'm not advocating either side right at the moment; my point is that the
manual is ambiguous (one might even say "coy") on this subject.
Indeed.
∂28-Mar-85 2216 cork%umass-cs.csnet@csnet-relay.arpa More on MAP, SOME, EVERY, etc.....
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 22:16:49 PST
Received: from umass-cs by csnet-relay.csnet id ab02829; 29 Mar 85 1:02 EST
Date: Thu, 28 Mar 85 09:26 EST
From: Dan Corkill <cork%umass-cs.csnet@csnet-relay.arpa>
To: common-lisp@su-ai.ARPA
Subject: More on MAP, SOME, EVERY, etc.....
I'm not certain this made it through the network.....
------------------------------------------------------------------------------
As I expected, my flame about MAP, SOME, EVERY, etc. has raised some
important issues.....
First, RAM suggests that viewing a circular list as a dotted list
avoids the problem:
> The definition of a normal list in the Lists chapter is one
> terminated by NIL. By this definition, a circular list is a dotted
> list. I believe that there was a decision at one point that functions
> which use lists as sequences (a superset of the sequence functions)
> are allowed to complain about dotted lists. This is implied by the
> statement that Endp is the canonical list-end predicate.
However, the next sentence from that chapter argues that a circular
list CANNOT be a dotted list:
``A list whose cdr chain is terminated by some non-nil atom is called
a dotted list.'' Clearly, a circular list is not terminated by some
non-NIL atom (is it terminated at all?), and ENDP cannot be used to
detect a circular list.
~~ An aside --- As the CLM is unclear on whether or not a circular is
~~ is an ORDINARY or DOTTED list, I would argue that it is better
~~ viewed as an ORDINARY list. In a sense a circular list is a list
~~ that shares structure with itself. Unless destructive functions
~~ are applied to a circular list, it behaves identically to an
~~ infinite list. Further supporting this position is the observation
~~ that mapc, mapcar, etc. work with circular list arguments and
~~ generate errors with dotted (non-circular) list arguments.
*** Back to the original complaint about MAP, SOME, EVERY, etc. ***
Under the premise that a circular list is NOT a dotted list, the
implementation of MAP, SOME, EVERY, etc. should not care whether
or not an argument sequence is circular or not. (It should be
up to the user to worry about the effects of any destructive
changes to an arglist. I suggest that all the following should
be legal:
(map 'list '+ '(1 2 3) (star 5)) => (6 7 8)
;; (defun star (&REST arglist)
;; (nconc arglist arglist))
(some 'char< "string" (star #\x)) => t
(map 'array '#(2 3 4) (star 5)) => #(7 8 9)
(replace '(1 2 3 4 5) (star -1)
:START1 2 :END1 4)) => (1 2 -1 -1 5)
;; Note that (replace (star -1) '(1 2 3 4 5) :start1 2 :end1 4)
;; should not be expected to produce (-1 -1 1 2 -1 ... ). But
;; should be undefined as to what it does.
I agree with Dave Dyer that the programmer shouldn't have to know anything
about the lists passed to MAPxxx except that the shortest sequence (if a
list) is a proper list.
I would hope that even the following would be legal:
(map 'list '+ '(1 2 3) '(1 2 3 4 5 . 6)) => (2 4 6)
I also agree that the use of LENGTH for lists is a poor implementation
technique, and Dave's admonition against the use of LENGTH in system
functions unless all elements are guaranteed to be inspected is
reasonable.
In summary, I believe that implementations of MAP, SOME, EVERY, etc.
using LENGTH do not follow the semantics of the CLM and are inconsistent
with the usual behavior of the traditional list mapping functions.
I strongly suggest that it is the implementations that are incorrect
rather than ambiguity in the semantics and argue that merely changing
the descriptions to explicitly exclude circular lists greatly curtails
the utility of the sequence functions.
Dan Corkill
Cork@UMass
------------------------------------------------------------------------------
∂29-Mar-85 2041 TIM@MIT-MC multiple-value-setf
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 29 Mar 85 20:41:27 PST
Date: 29 March 1985 23:41-EST
From: Tim McNerney <TIM @ MIT-MC>
Subject: multiple-value-setf
To: Fahlman @ CMU-CS-C
cc: common-lisp @ SU-AI, eak @ S1-B
In-reply-to: Msg of Wed 27 Mar 1985 19:39 EST from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Granted that it is relatively easy to write a multiple-value-setf,
it probably should have been included in the language to begin
with. I had several uses for it and was forced to write my own.
∂01-Apr-85 0118 masinter.pa@Xerox.ARPA Re: Arg count checking
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 1 Apr 85 01:18:21 PST
Received: from Semillon.ms by ArpaGateway.ms ; 01 APR 85 01:18:18 PST
Date: 1 Apr 85 01:00 PST
From: masinter.pa@XEROX.ARPA
Subject: Re: Arg count checking
In-reply-to: various messages
To: bug-1100@SUMEX-AIM.ARPA
cc: common-lisp@SU-AI.ARPA
The only places I've seen extra args used in situations where it isn't
(clearly) a bug is in code that is dealing with two different
implementations.
Implementation A has a function FOO with args A B and an optional C.
Implementation B has a function FOO with args A B. No optional.
You can then write a client that will work with both implementations, as
long as it knows that some implementations may ignore the last argument.
(Most of the cases I've seen have been ones where its been a "flag",
e.g. implementation A has a "slow" and a "fast" case, and you can say
(FOO 1 2 T) and it means do (FOO 1 2) and, if you care, do it fast
rather than slow..., although there have been other uses.)
I can think of about a half-dozen cases of this, off hand; e.g., the
"standard system" has a vanilla WHEREIS, but there's a super-WHEREIS
that takes lots of args, and it redefines WHEREIS to have lots of
optionals.
The odd thing is that I can't think of a really clean way of doing
this-- having variant argument lists in different implementations -- I
suppose you'd have to write a &REST in every implementation that didn't
have the args.
Another place this arises are in mapping functions which take functional
arguments; they apply the functional arg; sometimes they pass extra
arguments which of course the functional is free to ignore.
All of these are instances where the CALLER knows the args are optional.
I can imagine (not very seriously) a separate syntax for that, e.g., put
the &OPTIONAL on the caller rather than the callee:
(FOO 1 2 &OPTIONAL T) which says to call FOO with 2 arguments, and throw
away the third if FOO only takes two arguments, but otherwise pass it
all three.
Can this be different than multiple-value-return where the caller is
expecting fewer values than the callee returns?
∂01-Apr-85 1123 godot!gls@cca-unix [Gall: Bug Report]
Received: from CCA-UNIX.ARPA by SU-AI.ARPA with TCP; 1 Apr 85 11:23:08 PST
Received: by cca-unix.ARPA (4.12/4.7)
id AA25503; Mon, 1 Apr 85 14:18:04 est
Message-Id: <8504011918.AA25503@cca-unix.ARPA>
Received: by godot with CHAOS id AA04348; Mon, 1 Apr 85 13:46:19 est
Date: Monday, 1 April 1985, 13:46-EST
From: Guy Steele <godot!gls@cca-unix>
Subject: [Gall: Bug Report]
To: Moon%SCRC-STONY-BROOK.ARPA@GODOT, common-lisp%SU-AI.ARPA@GODOT
Cc: gls@AQUINAS
In-Reply-To: <850327200955.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I have been tracking comments on ambiguities and lack of clarity
in the manual, and have been making a list of "small" (not substantive)
changes which might be incorporated in the next printing. While I
expect no objections to the changes, I will circulate the list well
before sending it to Digital Press.
--Guy
∂01-Apr-85 1127 godot!gls@cca-unix Implementation of MAP, SOME, EVERY, etc...
Received: from CCA-UNIX.ARPA by SU-AI.ARPA with TCP; 1 Apr 85 11:27:19 PST
Received: by cca-unix.ARPA (4.12/4.7)
id AA25468; Mon, 1 Apr 85 14:16:46 est
Message-Id: <8504011916.AA25468@cca-unix.ARPA>
Received: by godot with CHAOS id AA04234; Mon, 1 Apr 85 13:38:48 est
Date: Monday, 1 April 1985, 13:39-EST
From: Guy Steele <godot!gls@cca-unix>
Subject: Implementation of MAP, SOME, EVERY, etc...
To: Moon%SCRC-STONY-BROOK.ARPA@GODOT,
cork%umass-cs.csnet%CSNET-RELAY.ARPA@GODOT
Cc: common-lisp%SU-AI.ARPA@GODOT, gls@AQUINAS
In-Reply-To: <850327161712.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Received: by godot id AA28148; Wed, 27 Mar 85 22:11:41 est
Received: from SU-AI.ARPA (su-ai.arpa.ARPA) by cca-unix.ARPA (4.12/4.7)
id AA24285; Wed, 27 Mar 85 21:34:41 est
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 13:39:50 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204367; Wed 27-Mar-85 16:16:13-EST
Date: Wed, 27 Mar 85 16:17 EST
From: David A. Moon <cca!Moon%SCRC-STONY-BROOK.ARPA@godot>
Subject: Implementation of MAP, SOME, EVERY, etc...
To: Dan Corkill <cork%umass-cs.csnet%CSNET-RELAY.ARPA@godot>
Cc: common-lisp%SU-AI.ARPA@godot
In-Reply-To: The message of 19 Mar 85 11:58-EST from Dan Corkill <cork%umass-cs.csnet@csnet-relay.arpa>
Message-Id: <850327161712.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comment: Message remailed after delay caused by distribution list error.
Date: Tue, 19 Mar 85 11:58 EST
From: Dan Corkill <cork%umass-cs.csnet@csnet-relay.arpa>
There is an easily made implementation error in MAP, SOME, EVERY, etc.
The published semantics indicate that these functions use the length of
the shortest argument sequence to determine how many iterations to
perform (and in this way parallel the semantics of mapc, mapcar, etc.).
Thus it would appear that:
(map 'list '+ '(1 2 3) (star 2))
where star builds a circular list of its argument should be legal and
return => (3 4 5).
Implementations that use length to check the length of argument sequences
will break on such a call.
The Common Lisp LENGTH function returns NIL when given a circular list.
From the Common Lisp manual, page 265:
"LIST-LENGTH differs from LENGTH when the list is circular;
LENGTH may fail to return, whereas LIST-LENGTH will return NIL."
∂01-Apr-85 1844 KMP@SCRC-QUABBIN.ARPA Re: Arg count checking
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 1 Apr 85 18:44:26 PST
Received: from SCRC-RIO-DE-JANEIRO by SCRC-YUKON via CHAOS with CHAOS-MAIL id 98514; Mon 1-Apr-85 21:43:55-EST
Date: Mon, 1 Apr 85 21:43 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Re: Arg count checking
To: masinter.pa@XEROX.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 1 Apr 85 04:00-EST from masinter.pa@XEROX.ARPA
Message-ID: <850401214307.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
[Removed Bug-1100@SUMEX-AIM]
Date: 1 Apr 85 01:00 PST
From: masinter.pa@XEROX.ARPA
Subject: Re: Arg count checking
In-reply-to: various messages
To: bug-1100@SUMEX-AIM.ARPA
cc: common-lisp@SU-AI.ARPA
The only places I've seen extra args used in situations where it isn't
(clearly) a bug is in code that is dealing with two different
implementations.
Implementation A has a function FOO with args A B and an optional C.
Implementation B has a function FOO with args A B. No optional.
You can then write a client that will work with both implementations, as
long as it knows that some implementations may ignore the last argument.
(Most of the cases I've seen have been ones where its been a "flag",
e.g. implementation A has a "slow" and a "fast" case, and you can say
(FOO 1 2 T) and it means do (FOO 1 2) and, if you care, do it fast
rather than slow..., although there have been other uses.)
I can think of about a half-dozen cases of this, off hand; e.g., the
"standard system" has a vanilla WHEREIS, but there's a super-WHEREIS
that takes lots of args, and it redefines WHEREIS to have lots of
optionals.
The odd thing is that I can't think of a really clean way of doing
this-- having variant argument lists in different implementations -- I
suppose you'd have to write a &REST in every implementation that didn't
have the args.
The proper solution would have been for the person who wrote the
super-WHEREIS to call it something else (or in a language like CL,
use the same name but put it in a different package). Then old code still
calls the old utility and new code can call the new super-WHEREIS.
Even if the super-WHEREIS fixes some misfeature the old WHEREIS wants,
the writer should have done
(DEFUN WHEREIS (...compatible-args...) (SUPER-WHEREIS ...whatever...))
(DEFUN SUPER-WHEREIS (...hairy-args...) ...)
so that people wouldn't be tempted to call the existing WHEREIS with
the hairy args and get into the situation you're talking about.
It's the fault of the person who created the new FOO abstraction
without giving it a new name that you are in this mess.
If (FOO x y) and (FOO x y z) does already exist in two implementations,
you should just write your own GENERALIZED-FOO abstraction that does
(DEFUN GFOO (X Y &REST Z)
(COND ((MEMQ 'HAIRY-FOO *FEATURES*) (APPLY #'FOO X Y Z))
(T (FOO X Y))))
or some macroesque equivalent (if you're an efficiency fiend).
Another place this arises are in mapping functions which take functional
arguments; they apply the functional arg; sometimes they pass extra
arguments which of course the functional is free to ignore.
This is interesting. I hadn't ever thought about
(MAPCAR #'(LAMBDA (X &OPTIONAL (Y 0)) (LIST X Y)) '(A B C D) '(1 2))
I suppose one could argue that returning ((A 1) (B 2) (C 0) (D 0)) would
have been the "right" thing. Of course,
(MAPCAR #'(LAMBDA (&OPTIONAL (X 0) (Y 0)) (LIST X Y)) '(A B C D) '(1 2))
might have been a little harder to deal with ... since presumably that
just wouldn't return... of course, the fact that
(MAPCAR #'(LAMBDA (&OPTIONAL (X 0)) (PRINT X)))
loops indefinitely rather than returning argues in favor of such a position.
... I think.
All of these are instances where the CALLER knows the args are optional.
I can imagine (not very seriously) a separate syntax for that, e.g., put
the &OPTIONAL on the caller rather than the callee:
(FOO 1 2 &OPTIONAL T) which says to call FOO with 2 arguments, and throw
away the third if FOO only takes two arguments, but otherwise pass it
all three.
This is certainly consistent with the symmetry provided in the allow-other-keys
portion of the keyword arg specs.
Somehow this bothers me; I'm at a loss to say exactly why, though. But I
think it also bothers me that :ALLOW-OTHER-KEYS is there (for reasons beyond
the obvious fact that it's an ugly special case in the middle of the keyword
namespace), so don't take it too personally. I think it has something to do
with the fact that it means you're really trying to shoehorn an additional
abstraction in where room wasn't provided. ie, the real problem is that all
the old code is still calling FOO instead of GENERIC-FOO. I guess I think
that's just a bug in that code.
Can this be different than multiple-value-return where the caller is
expecting fewer values than the callee returns?
I definitely agree these two issues are not different. I think this just
shows that what multiple value return does is wrong. I've held the position
for quite some time that multiple values should have to be &OPTIONAL'd
and &REST'd. I believe there are others on this committee who side with me,
but we were in the minority in the discussions leading up to the current spec.
Perhaps that will change with time.
∂02-Apr-85 0745 DLW@SCRC-QUABBIN.ARPA Re: Arg count checking
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 07:44:51 PST
Received: from SCRC-CHICOPEE by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 149181; Tue 2-Apr-85 10:39:25-EST
Date: Tue, 2 Apr 85 10:46 EST
From: Daniel L. Weinreb <DLW@SCRC-STONY-BROOK.ARPA>
Subject: Re: Arg count checking
To: KMP@SCRC-STONY-BROOK.ARPA, masinter.pa@XEROX.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850401214307.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <850402104635.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Mon, 1 Apr 85 21:43 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
This is interesting. I hadn't ever thought about
(MAPCAR #'(LAMBDA (X &OPTIONAL (Y 0)) (LIST X Y)) '(A B C D) '(1 2))
I suppose one could argue that returning ((A 1) (B 2) (C 0) (D 0)) would
have been the "right" thing.
You'd have to change the definition of MAPCAR. Currently it's defined
to stop after any of the lists run out. You'd have to change it;
perhaps to say that it should keep going until ALL of the lists run out,
but the old rule was there for a reason. Or that it should stop as soon
as any of the lists that are being used as "required" argument run out,
although that's on the hirsute side.
Of course,
(MAPCAR #'(LAMBDA (&OPTIONAL (X 0) (Y 0)) (LIST X Y)) '(A B C D) '(1 2))
might have been a little harder to deal with ... since presumably that
just wouldn't return...
No. Under any of the possibilities above, it must terminate after four steps.
of course, the fact that
(MAPCAR #'(LAMBDA (&OPTIONAL (X 0)) (PRINT X)))
loops indefinitely rather than returning argues in favor of such a position.
... I think.
The first list argument to MAPCAR is required, so this simply bombs out with
too few arguments to MAPCAR.
I definitely agree these two issues are not different. I think this just
shows that what multiple value return does is wrong. I've held the position
for quite some time that multiple values should have to be &OPTIONAL'd
and &REST'd. I believe there are others on this committee who side with me,
but we were in the minority in the discussions leading up to the current spec.
Perhaps that will change with time.
That's right. This was argued to death, and the present behavior was
arrived at after lots of discussion about both (and other) schemes.
∂02-Apr-85 1201 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: PROCLAIM [Gall: Bug Report]
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 12:01:32 PST
Date: Tue, 2 Apr 85 14:58 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: Re: PROCLAIM [Gall: Bug Report]
To: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 28 Mar 85 09:28 EST from "Network←Server.Daemon (Moon@SCRC-STONY-BROOK.ARPA@SU-AI)"
Message-ID: <850402195849.627063@MIT-MULTICS.ARPA>
!section 9.1(12) Nick Gall 85-03-19
!version Digital Press 1984
!topic Non-Top-Level use of PROCLAIM
Some mention of the effects of the non-top-level use of PROCLAIM
and the other proclaiming forms should be made.
On p.66 it says that DEFVAR is not allowed elsewhere than top-level.
PROCLAIM is the only function (rather than special form) that makes
declarations, and presumably the declarations it makes when it is
called take effect "immediately", but the exact definition of "immediately"
might be implementation-dependent. For example, it is implementation-
dependent whether PROCLAIM affects interpreted functions that have already
been defined.
I guess what really bothers me about the definition of proclaim
is the following sentence:
This allows a program to compute a declaration and then
put it into effect by calling proclaim. (pg. 156)
This encourages a style that is bound to bring out an
inconsistency in between the semantics assigned to a correct
program by the compiler and the interpreter.
Is there a STRONG reason for allowing run-time declares? If not,
I think the above sentence should be struck, and proclaim's usage
restricted to DEFVAR, etc., and top-level.
≠
∂02-Apr-85 1201 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: INTERN [Gall: Bug Report]
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 12:00:57 PST
Date: Tue, 2 Apr 85 14:57 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: Re: INTERN [Gall: Bug Report]
To: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 28 Mar 85 09:28 EST from "Network←Server.Daemon (Moon@SCRC-STONY-BROOK.ARPA@SU-AI)"
Message-ID: <850402195716.255225@MIT-MULTICS.ARPA>
!section 11.7 Nick Gall 85-03-20
!version Digital Press 1984
!topic INTERN's effect on an accessible symbol's owner.
As a verb, to `intern' a symbol in a package means to
cause the symbol to be interned (sic) in the package if
it was not already; this function is performed by the
function INTERN. If the symbol was previously unowned,
then the package it is being interned in becomes its
owner (home package)...
CLRM Section 11.0 (pg. 172)
I interpret this passage in the following way:
;; Current package is USER
* (setf p1 (make-package 'p1 :use '()))
{printed rep. of p1}
* (import 'p1::xyzzy)
T
* (symbol-package 'xyzzy)
{printed rep. of p1}
* (unintern 'xyzzy p1)
T
* (symbol-package 'xyzzy)
NIL ;; At this point, xyzzy is an accessible uninterned symbol.
* (intern "XYZZY")
XYZZY
:INTERNAL
* (symbol-package 'xyzzy)
{printed rep. of user}
In other words, INTERN ensures that the symbol that it returns
as its first value has a home package.
Is this interpretation correct?
I think the mention of accessible but unowned symbols on page 172 (in the
discussion of home packages) shoots down your example. The result of the
last call to SYMBOL-PACKAGE is probably undefined.
I don't understand your response. The mention of accessible but
unowned symbols on page 172 merely confirms the possibility of
accessible uninterned symbols. I fully agree that such beasts
may exist. In fact, I have annotated the above code to show that
BEFORE the intern is done, xyzzy is an accessible uninterned
symbol.
My contention is that the above call to INTERN should (according
to my interpretation of the CLRM and for practical reasons which
I will point out below) change xyzzy from an accessible
uninterned symbol into an interned symbol (simply by updating its
package cell).
If the symbol was previously unowned, then the package it is
being interned in becomes its owner (home package); but if the
symbol was previously owned by another package, that other
package continues to own the symbol.
This sentence strongly suggests to me that intern does affect
accessible uninterned symbols.
If intern does not update an accessible symbol whose package cell
contains NIL, there is NO WAY to change the home package of the
symbol. I can't give it a new home!
Suppose I defun foo in the user package. Then I decide that it
`belongs' in my tool package. The best I can do now is
* (import 'foo 'tool)
T
* (unintern 'foo)
T
But whenever foo is printed, it will print as #:foo. This is
unacceptable.
∂02-Apr-85 1218 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: NIL and DEFCONSTANT [Gall: Bug Report]
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 12:16:52 PST
Date: Tue, 2 Apr 85 15:06 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: Re: NIL and DEFCONSTANT [Gall: Bug Report]
To: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 28 Mar 85 09:28 EST from "Network←Server.Daemon (Moon@SCRC-STONY-BROOK.ARPA@SU-AI)"
Message-ID: <850402200658.769017@MIT-MULTICS.ARPA>
!section 20.1(last-1) Nick Gall 85-03-19
!version Digital Press 1984
!topic Is nil declared by defconstant?
...all constant symbols declared by DEFCONSTANT, such as NIL,
T, and PI.
If NIL is declared by DEFCONSTANT then it can legally be
redefined according to section 5.1.2(last):
Constant symbols defined by DEFCONSTANT ... may be redefined,
if necessary, by using DEFCONSTANT again[].
Is such an interpretation correct?
I do not believe that system-supplied constants can legally be redefined.
Is it that my interpretation is incorrect (and if so why?) or is
it that the CLRM is incorrect (and if so how?).
≠
∂02-Apr-85 1218 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: SPECIAL FUNCTION NAME [Gall: Bug Report]
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 12:16:02 PST
Posted-Date: 2 Apr 85 15:04 EST
Date: Tue, 2 Apr 85 15:01 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: Re: SPECIAL FUNCTION NAME [Gall: Bug Report]
To: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 28 Mar 85 09:28 EST from "Network←Server.Daemon (Moon@SCRC-STONY-BROOK.ARPA@SU-AI)"
Message-ID: <850402200150.524049@MIT-MULTICS.ARPA>
!section 7.5(14) Nick Gall 85-03-19
!version Digital Press 1984
!topic Scope and Extent of local function names
See above comment about the implications of FLET and LABELS not having
been fully thought out and reflected in the manual.
I suggest that Common Lisp go all the way, and allow a
SPECIAL-FUNCTION-NAME declaration that would be analogous to the
SPECIAL declaration for "ordinary" variables.
Such a concept would make the idea of
ordinary-variable/function-name binding and assignment much more
consistent.
As I recall this was considered and rejected on the basis that it would
be confusing and wouldn't give any real increase in expressive power
(since FUNCALL of a special variable could be used). I agree with that
decision, even though our implementation has always had the feature.
The only place where we use it is in a crock that could just as well be
done some other way.
I think that a thought out explanation of FLET and LABELS would
allow a SPECIAL-FUNCTION-NAME declaration to be described in
perspicuous manner.
As for its usefulness, I am writing a command processor, and I
wish to prevent the user from typing in forms that might abort
the processor (e.g., (exit), (reset-stack-group), etc.). FLET
would allow me to establish temporary global function definitions
for these dangerous functions. The code would be much clearer
than saving the old function definitions, doing defuns (or setfs
of symbol-functions) and then restoring the old definitions.
≠
∂02-Apr-85 1218 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: [Gall: Bug Report]
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 12:18:08 PST
Posted-Date: 2 Apr 85 15:15 EST
Date: Tue, 2 Apr 85 15:12 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: Re: [Gall: Bug Report]
To: "Daniel L. Weinreb" <DLW@SCRC-STONY-BROOK.ARPA>
cc: Moon@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: Message of 28 Mar 85 16:56 EST from "Daniel L. Weinreb"
Message-ID: <850402201250.950711@MIT-MULTICS.ARPA>
Date: 28 March 1985 16:56 est
From: Daniel L. Weinreb <DLW at SCRC-STONY-BROOK>
Subject: [Gall: Bug Report]
Date: Wed, 27 Mar 85 20:09 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
were EVAL-WHEN permitted inside a function body (it is not; see p.66).
...
On p.66 it says that DEFVAR is not allowed elsewhere than top-level.
Are we reading the same page 66? Mine says "It is not illegal to use
these forms at other than top level, but whether it is meaningful to do
so depends on context." To my ears, this is sort of like saying
that integers can be of any precision, but after they get larger
than the fixnum limit, their behavior depends on context.
Also, note the wording in the description of DEFUN on page 67: "Because
DEFUN forms normally appear at top level, this is normally the null
lexical environment." This wording strongly suggests that DEFUN might
sometimes not be at top level, and the environment is not necessarily
always null. After all, if DEFUN were only allowed at top-level, why
bother with the "normally" qualifiers? But you never find out anything
further.
I'm not advocating either side right at the moment; my point is that the
manual is ambiguous (one might even say "coy") on this subject.
Hmm! I thought ALL integers were infinitely precise.
As to defuns at other that top level, on pg. 67 it says
Evaluating a defun form causes the symbol NAME to be a global
name for the function specified by the
lambda-expression...DEFINED IN THE LEXICAL ENVIRONMENT IN
WHICH THE defun WAS EXECUTED.
I take this to mean that the CLRM specifically allows and defines
the correct semantics for non-top-level use of DEFUN.
I think pg. 66 is what needs cleaning up (i.e., it should
enumerate the correct uses of `Top-Level' forms). "Depends on
context" is equivalent to "is undefined" in my book.
≠
∂02-Apr-85 1218 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: COPY-SYMBOL [Gall: Bug Report]
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 12:16:27 PST
Date: Tue, 2 Apr 85 15:05 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: Re: COPY-SYMBOL [Gall: Bug Report]
To: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 28 Mar 85 09:28 EST from "Network←Server.Daemon (Moon@SCRC-STONY-BROOK.ARPA@SU-AI)"
Message-ID: <850402200539.663972@MIT-MULTICS.ARPA>
!section 10.3(9) Nick Gall 85-03-19
!version Digital Press 1984
!topic Which bindings are copied by COPY-SYMBOL?
"the initial value and function-definition of the new symbol
will be the same as those of SYM..."
Does this mean that the (dynamic) value of the variable
referred to by SYM, at the point where COPY-SYMBOL symbol is
invoked, is copied? Or, does it mean that the `initial', i.e.
global value of the special variable named by SYM is copied?
Although the wording seems to suggest the latter, it should be
made clearer.
The word "initial" was meant to refer to the new symbol, not the old
symbol, I believe. Probably no one realized the English could be
regarded as ambiguous.
The same questions and suggestion applies to the
function-definition copied by COPY-SYMBOL.
What confused me in the defintion of COPY-SYMBOL was the phrase,
"the initial value and function definition of the NEW SYMBOL"
[emphasis mine N.G.]. Symbols do not have values and/or function
defintions in CL (or at least they are not required to), a point
made very well on pg. 163. The language should be more like "the
initial value of the dynamic variable NAMED BY THE new symbol..."
≠
∂02-Apr-85 1327 JAR@MIT-MC SPECIAL FUNCTION NAME [Gall: Bug Report]
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 13:27:03 PST
Date: 2 April 1985 16:26-EST
From: Jonathan A Rees <JAR @ MIT-MC>
Subject: SPECIAL FUNCTION NAME [Gall: Bug Report]
To: Gall @ MIT-MULTICS
cc: common-lisp @ SU-AI
Date: Tue, 2 Apr 85 15:01 EST
From: Nick Gall <Gall at MIT-MULTICS.ARPA>
...As for its usefulness, I am writing a command processor, and I
wish to prevent the user from typing in forms that might abort
the processor (e.g., (exit), (reset-stack-group), etc.). FLET
would allow me to establish temporary global function definitions
for these dangerous functions. The code would be much clearer
than saving the old function definitions, doing defuns (or setfs
of symbol-functions) and then restoring the old definitions.
I think that special function binding was explicitly and intentionally
omitted from CL. Symmetry with variables would suggest that they are
desirable, but there were reasons for their omission (descriptive and
implementation simplicity come to mind).
You could do what you need to do by implementing yourself a sort of
generalized special binding which is symmetric with SETF instead of with
SETQ, using UNWIND-PROTECT:
(SETF-TEMPORARILY place value-form
... body-forms ...)
could expand into something like
(LET ((SAVED-VALUE place))
(UNWIND-PROTECT (PROGN (SETF SAVED-VALUE place)
... body-forms ...)
(SETF place SAVED-VALUE)))
(with appropriate DEFSETF-like hair). Now you have a much more
symmetrical facility, which will work not only with function bindings
(take place = (SYMBOL-FUNCTION ...)) but any other kind of location -
including CAR's of lists, lexical variables (!), etc. (Think about it.)
We've been using exactly this facility in T (Yale Scheme) for quite a
while (in fact, it replaces specbinding altogether) and it's pretty
nice. Perhaps even a little too powerful.
You run into problems if you're running in a multitasking or
multiprocessing environment. Presumably special variable bindings are
local to a process in any such system (whether deep- or shallow-bound).
If you're multitasking you could imagine an UNWIND-PROTECT primitive for
changing dynamic state going from one process to another, so that you
could specbind arbitrary places; but this totally breaks down in a
multiprocessor system, where deep binding would be necessary. How do
you deep-bind the car of a pair, or the 13th bit of a bit-vector? That
would argue in favor of permitting function specbinding by special
dispensation, although how you'd implement it efficiently I can't
imagine.
For this particular application, though, isn't the right thing just to
set up a separate package?...
Jonathan
∂02-Apr-85 1329 fateman%ucbdali@Berkeley CLRM?
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 13:24:51 PST
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.42)
id AA22191; Tue, 2 Apr 85 12:50:14 pst
Received: by ucbdali.ARPA (4.24/4.42)
id AA02474; Tue, 2 Apr 85 12:50:16 pst
Date: Tue, 2 Apr 85 12:50:16 pst
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8504022050.AA02474@ucbdali.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: CLRM?
I think this is what I call CLTL (Common Lisp the Language). I am perhaps
guilty of wishful thinking to hope that a CLRM (Common Lisp Reference Manual)
will be a different, perhaps public domain, document. Is there any hope of
this happening? In the meantime, I will wait for CLTM, (Common Lisp the
Movie) and TWK (The numeric supplement... The Wrath of Kahan ).
∂02-Apr-85 1722 Moon@SCRC-STONY-BROOK.ARPA Re: NIL and DEFCONSTANT [Gall: Bug Report]
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 17:17:01 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 207707; Tue 2-Apr-85 19:27:57-EST
Date: Tue, 2 Apr 85 19:28 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: NIL and DEFCONSTANT [Gall: Bug Report]
To: Nick Gall <Gall@MIT-MULTICS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850402200658.769017@MIT-MULTICS.ARPA>
Message-ID: <850402192844.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 2 Apr 85 15:06 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
!section 20.1(last-1) Nick Gall 85-03-19
!version Digital Press 1984
!topic Is nil declared by defconstant?
...all constant symbols declared by DEFCONSTANT, such as NIL,
T, and PI.
If NIL is declared by DEFCONSTANT then it can legally be
redefined according to section 5.1.2(last):
Constant symbols defined by DEFCONSTANT ... may be redefined,
if necessary, by using DEFCONSTANT again[].
Is such an interpretation correct?
From: Moon
I do not believe that system-supplied constants can legally be redefined.
Is it that my interpretation is incorrect (and if so why?) or is
it that the CLRM is incorrect (and if so how?).
The CLRM is not self-consistent. As I said, I do not believe that system-supplied
constants can legally be redefined, so where the CLRM says or implies that they can
be it is wrong, in my opinion, and where it says or implies that they cannot be
it is not wrong.
∂02-Apr-85 1724 Moon@SCRC-STONY-BROOK.ARPA Re: INTERN [Gall: Bug Report]
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 17:18:21 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 207711; Tue 2-Apr-85 19:40:43-EST
Date: Tue, 2 Apr 85 19:41 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: INTERN [Gall: Bug Report]
To: Nick Gall <Gall@MIT-MULTICS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850402195716.255225@MIT-MULTICS.ARPA>
Message-ID: <850402194129.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Sorry about the long message but I can't justify deleting any of
the context yet. Summary of conclusions at the end.
Date: Tue, 2 Apr 85 14:57 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
!section 11.7 Nick Gall 85-03-20
!version Digital Press 1984
!topic INTERN's effect on an accessible symbol's owner.
As a verb, to `intern' a symbol in a package means to
cause the symbol to be interned (sic) in the package if
it was not already; this function is performed by the
function INTERN. If the symbol was previously unowned,
then the package it is being interned in becomes its
owner (home package)...
CLRM Section 11.0 (pg. 172)
I interpret this passage in the following way:
;; Current package is USER
* (setf p1 (make-package 'p1 :use '()))
{printed rep. of p1}
* (import 'p1::xyzzy)
T
* (symbol-package 'xyzzy)
{printed rep. of p1}
* (unintern 'xyzzy p1)
T
* (symbol-package 'xyzzy)
NIL ;; At this point, xyzzy is an accessible uninterned symbol.
* (intern "XYZZY")
XYZZY
:INTERNAL
* (symbol-package 'xyzzy)
{printed rep. of user}
In other words, INTERN ensures that the symbol that it returns
as its first value has a home package.
Is this interpretation correct?
I think the mention of accessible but unowned symbols on page 172 (in the
discussion of home packages) shoots down your example. The result of the
last call to SYMBOL-PACKAGE is probably undefined.
I don't understand your response. The mention of accessible but
unowned symbols on page 172 merely confirms the possibility of
accessible uninterned symbols. I fully agree that such beasts
may exist. In fact, I have annotated the above code to show that
BEFORE the intern is done, xyzzy is an accessible uninterned
symbol.
To amplify my response, I don't feel that when INTERN finds an already
accessible symbol (rather than creating a new one), that it "interns
the symbol". I think the symbol is already interned and INTERN shouldn't
mess with its home package. Of course this is a matter of interpretation
and perhaps you are right. The implementation might be expensive in some
systems, though.
My contention is that the above call to INTERN should (according
to my interpretation of the CLRM and for practical reasons which
I will point out below) change xyzzy from an accessible
uninterned symbol into an interned symbol (simply by updating its
package cell).
If the symbol was previously unowned, then the package it is
being interned in becomes its owner (home package); but if the
symbol was previously owned by another package, that other
package continues to own the symbol.
This sentence strongly suggests to me that intern does affect
accessible uninterned symbols.
Oh my. The sentence you quote (on p. 172) appears to be left over from
the days when INTERN would allow a symbol as its argument. The language
was later changed to permit only strings as arguments to INTERN. But if
this isn't really a left-over, then it is evidence for your position.
If intern does not update an accessible symbol whose package cell
contains NIL, there is NO WAY to change the home package of the
symbol. I can't give it a new home!
I think IMPORT was intended to be the way to do that. Again, the manual
does not appear to have been updated to reflect this after the arguments
allowed for INTERN were changed. SYMBOL-PACKAGE is also SETF'able in
our implementation, but apparently not in the standard language.
Suppose I defun foo in the user package. Then I decide that it
`belongs' in my tool package. The best I can do now is
* (import 'foo 'tool)
T
* (unintern 'foo)
T
But whenever foo is printed, it will print as #:foo. This is
unacceptable.
Do the operations in the other order. (Of course you have to read
the IMPORT form before evaluating the UNINTERN form). That works in
our implementation, although I admit it isn't crystal clear that that
is what the manual intends.
I think this issue may need to be referred to the (not yet existent)
technical committee on clarifications to the language. If you want my
own opinion, in summary:
- INTERN never changes the SYMBOL-PACKAGE of a symbol that it
did not just create.
- IMPORT sets the SYMBOL-PACKAGE to the package imported into
when given an uninterned symbol (more precisely, a symbol
whose SYMBOL-PACKAGE is NIL).
∂02-Apr-85 2002 FAHLMAN@CMU-CS-C.ARPA INTERN [Gall: Bug Report]
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 20:02:42 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 2 Apr 85 23:02:04-EST
Date: Tue, 2 Apr 1985 23:01 EST
Message-ID: <FAHLMAN.12100086792.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA, Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: INTERN [Gall: Bug Report]
In-reply-to: Msg of 2 Apr 1985 19:41-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
This concerns the recent exchange between Moon and Gall on how INTERN
should handle home packages. I will refrain from including all previous
context. Unfortunately, I read most of this mail on an 80-column screen
and if things get nested too deeply, each line starts on the next line.
First, let me say that this is probably not of world-shaking importance.
Home packages are just a convenience for the printer, so that if a
symbol isn't accessible in the current package, it can (usually) either
tell you some package where the symbol is accessible or flag the cases
in which a symbol is not accessible in any package. It is true that by
clever use of Unintern you can manage to create an accessible sysmbol
with no recorded home package. Unintern also allows you to screw
yourself in lots of other ways if you work hard at it. Yawn!
Having said that, it seems to me that Gall's original reading of the
manual is as reasonable as any other. This says that if Intern finds an
acessible symbol that has no home (as opposed to creating a new symbol),
it should bash the Symbol-Package cell to the value of the package in
which it is doing the interning. It is too much work to make sure that
every symbol that is accessible in any package always has a home
package, but when we trip over an anomalous case like this, we may as
well fix it. It seems intuitive that Intern should return a symbol that
is "interned", in the sense of being accessible and having a home.
Moon grants that this might be a reasonable implementation, but then
comments that implementing this might be expensive. I don't see where
the expense would be. If Intern creates a symbol, it sets the home
package; if Intern finds a symbol whose package cell is NIL, it again
sets the home package. Checking the home package for nillity is a tiny
expense compared to the hash-table lookups, etc.
The sentence on page 172 should more properly say "when a STRING is
interned in a package...", since as Moon points out you cannot intern a
symbol directly. However, I think that this passage makes sense despite
this, if you make the reasonable assumption that the "symbol" referred
to here is either the one that is created or the already accessible
symbol that is found, as the case may be.
We decided not to allow users to use SETF on Symbol-Package, since there
seemed to be no good use for this and since by diddling around with this
you can create some very confusing situations.
-- Scott
∂02-Apr-85 2021 FAHLMAN@CMU-CS-C.ARPA NIL and DEFCONSTANT [Gall: Bug Report]
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 20:15:02 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 2 Apr 85 23:14:24-EST
Date: Tue, 2 Apr 1985 23:14 EST
Message-ID: <FAHLMAN.12100089053.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA, Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: NIL and DEFCONSTANT [Gall: Bug Report]
In-reply-to: Msg of 2 Apr 1985 19:28-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
I agree with Moon that it "is an error" to redefine built-in constants.
It probably is not required that an implementation stop you from doing
this, but it would be a good idea.
I think that the description on page 56 is OK as it is. First it says
that there are built-in named constants that you don't get to change.
Here it talks about such things as T and NIL. Then it says that
"constant symbols defined by Defconstant" are also treated this way, but
that they may be redefined if necessary by using Defconstant again. I
don't see anything that would imply that T and NIL are implicitly
defined by Defconstant and that they are therefore redefinable.
-- Scott
∂03-Apr-85 1226 JLW INTERN and "intern" -- the unwise choice of terminology
To: Gall@MIT-MULTICS.ARPA, Moon@SCRC-STONY-BROOK.ARPA
CC: Common-Lisp@SU-AI.ARPA
I believe the confusion over the interning-an-unowned-symbol stems from
the misleading use of the verb "intern" on page 172, and I think I'd
rather see that part of the documentation fixed than have any change
in th semantics of INTERN, UNINTERN, and/or IMPORT.
The state of being "interned" clearly requires the symbol to be owned; and
the penultimate paragraph of the introductory to chapter 11 says "this process
[interning] is performed by the function INTERN." For these reasons, one
might be tempted to agree with Nick that every call to INTERN results in an
interned symbol; yet the definition of INTERN rather implies that when
a symbol is already accessible [note well: "accessible", not "interned"]
it is merely returned, without the modification to the home package
outlined for the case of when "no such symbol is found".
My recommendations are quite straightforward:
1) pick some other word to use in place of "interned" to describe the
state so laboriously depicted on page 172, so that the reader is not
tempted to jump to the conclusion that it is coextensive with INTERN'd
2) Introduce the user-level operation for modifying a symbol's package
"cell" [its home package]. As Nick has already pointed out, the
current design doesn't prevent one from damageing that cell, by
injudicious use of UNINTERN and/or IMPORT; and worse yet, it doesn't
provide any way to say precisely what you mean when you want to
change its home [which is different from merely IMPORTing it somewhere].
-- JonL --
∂03-Apr-85 1438 Gall.HIS←Guest@MIT-MULTICS.ARPA
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 3 Apr 85 14:37:41 PST
Date: Wed, 3 Apr 85 17:36 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
To: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 3 Apr 85 03:28 EST from "Network←Server.Daemon (REM@IMSSS@SU-AI.ARPA)"
Message-ID: <850403223620.774008@MIT-MULTICS.ARPA>
Date: 3 April 1985 03:28 est
From: Network←Server.Daemon (REM@IMSSS@SU-AI.ARPA)
Return-Path: <@MIT-MULTICS.ARPA,@SU-AI.ARPA:REM@IMSSS>
Received: from SU-AI.ARPA by MIT-MULTICS.ARPA TCP; 03-Apr-1985 03:28:38-est
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-03 00:23:16 PST (=GMT-8hr)
Date: 1985 April 02 23:36:01 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132116072764.G0391
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:Gall@MIT-MULTICS.ARPA
Subject:CL, INTERN, etc.
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM@MIT-MC.ARPA
> Date: Thu, 21 Mar 85 00:36 EST
> From: Nick Gall <Gall@MIT-MULTICS.ARPA>
>
> Thanks for the encouragement. Having previously worked on an Ada
> implementation effort, I was hoping that the Common Lisp spec. would
> have been as carefully and completely defined. But it's never to
> late, as long as there is a concerned community.
Well, it's more difficult to make substantive changes now, because
those who worked on the current version of the manual and have done
some implentation are unwilling to start all over now, which I
understand (PCNET pulled the rug out from under my software and
documentation too many times), but indeed perhaps it's never too late
to fix the document to say something consistent and reasonable.
> I am sending my replies to some of your replies to the
> Common-Lisp mailing list.
Ok. (I think I already saw some of them, I'm falling behind in
answering my netmail.)
> !section 11.7 Nick Gall 85-03-20
> !version Digital Press 1984
> !topic UNINTERNing a shadowing-symbol
> When uninterning a shadowing symbol (call it foo), UNINTERN
> collects all inherited symbols with the same print-name
> as foo, including foo (assuming foo was inherited). If the name
> conflict is only between foo and one other symbol, what sense
> does it make to signal a name conflict error and give the user a
> choice between shadow-importing foo and the other symbol. If the
> user chooses foo, it is no different from aborting from the
> error.
This plus later messages bring up a curious question. Originally
INTERN could take a symbol and put it in a hash table so it'd be
accessible by name in addition to by internal pointer. Any values or
properties it had would presumably be kept. But CL allows INTERN only
for strings (creating an symbol or finding an old one), so it never
modifies an existing non-interned identifier to make it itself
interned, it always makes a new symbol, thus it's impossible to keep
the old properties and value from the old symbol in the new one. I
this correct?
IMPORT can be used to "put [a symbol] in a hash table so it'd be
accessible by name...".
∂03-Apr-85 1502 JLW Assymetry between argument-passing and value-returning
To: common-lisp@SU-AI.ARPA
In view of the recent semi-suggestions that the logical similarity between
argument passing and value receiving be institutionalized in Common Lisp,
perhaps we ought to review some of the reasons as to why we *didn't* do
it in the first place.
For one thing, I believe the need to mediate the argument spectrum could be
done on either side -- the defining side or the calling side -- but that
doing it on the defining side is simpler. For example, it is possible
to correct a definition *** in one place *** that fixes up a whole
slew of differing calls (e.g., some calls passing 3 args, some passing
5 args, etc). Similarly, we would keep the calling side "simple" even when
multiple return values are expected (i.e., no &optional or &rest, and
no destructuring). For the cases where some dynamic variation *is*
desirable, well, APPLY permits full freedom on the caller side for argument
passing, and MULTIPLE-VALUE-LIST permits full freedom on the caller side for
receiving values; of course, these "full freedom" capabilities are consy,
but they aren't expected to be very important.
The case offered as a potential example needing (or rather,"wanting") some
caller control over the argument spectrum -- simple WHEREIS and extended
WHEREIS -- seems to be a clear case of buggy design. For example, suppose
a caller passes 6 arguments at a time when the 4-argument-only version
is resident. What could possibly be expected? Should one assume that the
extra two argments didn't convey any information, and can safely be discarded?
If so, then what is the point of the 6-argument version. If one takes the
obvious tactic of having the 4-argument version admit two optional aguments
and run a fatal error if either argument is passed in [or even perhaps
autoload the 6-argument version when the optionals are passed in] then
there is no "4-argument" version; both are in fact 6-argument functions,
although one of them is biased against the 5th and 6th args.
In short, if one wants downward compatibility, he has to design the low-end
function to do something reasonable with callers who request high-end
features.
-- JonL --
∂03-Apr-85 1556 BSG@SCRC-STONY-BROOK.ARPA Re: Arg count checking
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 3 Apr 85 15:47:58 PST
Received: from SCRC-CONCORD by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 208449; Wed 3-Apr-85 18:47:06-EST
Date: Wed, 3 Apr 85 18:48 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Re: Arg count checking
To: masinter.pa@XEROX.ARPA, bug-1100@SUMEX-AIM.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 1 Apr 85 04:00-EST from masinter.pa@XEROX.ARPA
Message-ID: <850403184831.0.BSG@CONCORD.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTI
Date: 1 Apr 85 01:00 PST
From: masinter.pa@XEROX.ARPA
All of these are instances where the CALLER knows the args are optional.
I can imagine (not very seriously) a separate syntax for that, e.g., put
the &OPTIONAL on the caller rather than the callee:
(FOO 1 2 &OPTIONAL T) which says to call FOO with 2 arguments, and throw
away the third if FOO only takes two arguments, but otherwise pass it
all three.
I have needed this some number of times; it has been discussed locally
around here some, but to no end.
Specifically, I had a function "A" with a functional argument. A's contract
includes not only its own argument list, but the set of arguments with which
it calls its functional argument. Some callees are not interested in
all of the things that A passes them. The callees can &REST IGNORE
the uninteresting arguments, or declare the arguments and ignore them.
I (and not many others) see a true lack of symmetry with ordinary
optional arguments. The whole reason &OPTIONAL exists is so that a
caller need not have or show knowledge of arguments in which he is not
interested: not have dummy variables, or have to give their name or
number. Every such argument[English,not Lisp] can be applied equally
well to the functional callees of functions accepting functional
arguments.
∂03-Apr-85 1749 Masinter.pa@Xerox.ARPA Re: SPECIAL FUNCTION NAME [Gall: Bug Report]
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 3 Apr 85 17:49:35 PST
Received: from Salvador.ms by ArpaGateway.ms ; 03 APR 85 17:49:37 PST
Date: 3 Apr 85 17:49 PST
From: Masinter.pa@XEROX.ARPA
Subject: Re: SPECIAL FUNCTION NAME [Gall: Bug Report]
In-reply-to: Jonathan A Rees <JAR@MIT-MC.ARPA>'s message of 2 Apr 85
16:26 EST
To: common-lisp@SU-AI.ARPA
"For this particular application, though, isn't the right thing just to
set up a separate package?..."
Not if you ever had some other function which called (exit). The intent
is to wall off the functionality, not the names.
∂03-Apr-85 1843 Moon@SCRC-QUABBIN.ARPA INTERN and "intern" -- the unwise choice of terminology
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 3 Apr 85 18:43:20 PST
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 150291; Wed 3-Apr-85 21:39:57-EST
Date: Wed, 3 Apr 85 21:43 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: INTERN and "intern" -- the unwise choice of terminology
To: Jon White <JLW@SU-AI.ARPA>
cc: Gall@MIT-MULTICS.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 3 Apr 85 15:26-EST from Jon White <JLW@SU-AI.ARPA>
Message-ID: <850403214317.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I agree completely with the enclosed message from Jon L.
Date: 03 Apr 85 1226 PST
From: Jon White <JLW@SU-AI.ARPA>
I believe the confusion over the interning-an-unowned-symbol stems from
the misleading use of the verb "intern" on page 172, and I think I'd
rather see that part of the documentation fixed than have any change
in th semantics of INTERN, UNINTERN, and/or IMPORT.
The state of being "interned" clearly requires the symbol to be owned; and
the penultimate paragraph of the introductory to chapter 11 says "this process
[interning] is performed by the function INTERN." For these reasons, one
might be tempted to agree with Nick that every call to INTERN results in an
interned symbol; yet the definition of INTERN rather implies that when
a symbol is already accessible [note well: "accessible", not "interned"]
it is merely returned, without the modification to the home package
outlined for the case of when "no such symbol is found".
My recommendations are quite straightforward:
1) pick some other word to use in place of "interned" to describe the
state so laboriously depicted on page 172, so that the reader is not
tempted to jump to the conclusion that it is coextensive with INTERN'd
2) Introduce the user-level operation for modifying a symbol's package
"cell" [its home package]. As Nick has already pointed out, the
current design doesn't prevent one from damageing that cell, by
injudicious use of UNINTERN and/or IMPORT; and worse yet, it doesn't
provide any way to say precisely what you mean when you want to
change its home [which is different from merely IMPORTing it somewhere].
∂03-Apr-85 1846 KSH@MIT-MC
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Apr 85 18:45:46 PST
Date: 3 April 1985 21:45-EST
From: Kjeld Hvatum <KSH @ MIT-MC>
To: Fahlman @ CMU-CS-C
cc: common-lisp @ SU-AI
Date: 04/03/85
From: Steve Bacher
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Subject: INTERN (Gall: Bug Report)
(Note: Please forgive absence of square brackets - I'm an IBM user.)
We decided not to allow users to use SETF on Symbol-Package, since there
seemed to be no good use for this and since by diddling around with this
you can create some very confusing situations.
It seems to me that this might be construed as a violation of the
LISP (hacker?) ethic, which provides the user with the ability to
manipulate his/her environment any which way {s}he wishes. Not
that CL is required to provide every tool in the book, especially
since it's straightforward enough to do your own DEFSETF for a
(SETF SYMBOL-PACKAGE ...) construct, but the above reasoning
seems a mite feeble, especially considering the degree of bashing
that *is* permitted by CL.
You should keep in mind that users have a way of discovering the
most amazing uses for features that originated as afterthoughts
or oversights. To say that users should be protected from
nonfunctionality and/or self-confusion runs counter to all that
I have been led to believe.
∂03-Apr-85 2043 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: INTERN [Gall: Bug Report]
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 3 Apr 85 20:43:01 PST
Posted-Date: 3 Apr 85 23:42 EST
Date: Wed, 3 Apr 85 23:38 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: Re: INTERN [Gall: Bug Report]
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
cc: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>,
common-lisp@SU-AI.ARPA
In-Reply-To: Message of 2 Apr 85 23:01 EST from "Scott E. Fahlman"
Message-ID: <850404043851.615892@MIT-MULTICS.ARPA>
Date: 2 April 1985 23:01 est
From: Scott E. Fahlman <Fahlman at CMU-CS-C>
Subject: INTERN [Gall: Bug Report]
This concerns the recent exchange between Moon and Gall on how INTERN
should handle home packages. I will refrain from including all previous
context. Unfortunately, I read most of this mail on an 80-column screen
and if things get nested too deeply, each line starts on the next line.
First, let me say that this is probably not of world-shaking importance.
Home packages are just a convenience for the printer, so that if a
symbol isn't accessible in the current package, it can (usually) either
tell you some package where the symbol is accessible or flag the cases
in which a symbol is not accessible in any package. It is true that by
clever use of Unintern you can manage to create an accessible sysmbol
with no recorded home package. Unintern also allows you to screw
yourself in lots of other ways if you work hard at it. Yawn!
Having said that, it seems to me that Gall's original reading of the
manual is as reasonable as any other. This says that if Intern finds an
acessible symbol that has no home (as opposed to creating a new symbol),
it should bash the Symbol-Package cell to the value of the package in
which it is doing the interning. It is too much work to make sure that
every symbol that is accessible in any package always has a home
package, but when we trip over an anomalous case like this, we may as
well fix it. It seems intuitive that Intern should return a symbol that
is "interned", in the sense of being accessible and having a home.
Moon grants that this might be a reasonable implementation, but then
comments that implementing this might be expensive. I don't see where
the expense would be. If Intern creates a symbol, it sets the home
package; if Intern finds a symbol whose package cell is NIL, it again
sets the home package. Checking the home package for nillity is a tiny
expense compared to the hash-table lookups, etc.
The sentence on page 172 should more properly say "when a STRING is
interned in a package...", since as Moon points out you cannot intern a
symbol directly. However, I think that this passage makes sense despite
this, if you make the reasonable assumption that the "symbol" referred
to here is either the one that is created or the already accessible
symbol that is found, as the case may be.
We decided not to allow users to use SETF on Symbol-Package, since there
seemed to be no good use for this and since by diddling around with this
you can create some very confusing situations.
-- Scott
I agree with you completely. I disagree with the recommendations given
by Jon L. White:
1) pick some other word to use in place of "interned" to describe the
state so laboriously depicted on page 172, so that the reader is not
tempted to jump to the conclusion that it is coextensive with INTERN'd
2) Introduce the user-level operation for modifying a symbol's package
"cell" [its home package]. As Nick has already pointed out, the
current design doesn't prevent one from damageing that cell, by
injudicious use of UNINTERN and/or IMPORT; and worse yet, it doesn't
provide any way to say precisely what you mean when you want to
change its home [which is different from merely IMPORTing it somewhere].
Since the CLRM already implies that INTERN may clobber the package cell
of an accessible symbol (an inexpensive operation) isn't it simpler (and
cleaner) to merely state it explicitly in the def. of INTERN (pg.184),
instead of changing pg. 172 AND inventing a WHOLE NEW user-level
operation (and a dangerous one at that)?
∂03-Apr-85 2105 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: NIL and DEFCONSTANT [Gall: Bug Report]
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 3 Apr 85 21:05:18 PST
Date: Wed, 3 Apr 85 23:52 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: Re: NIL and DEFCONSTANT [Gall: Bug Report]
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
cc: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>,
common-lisp@SU-AI.ARPA
In-Reply-To: Message of 2 Apr 85 23:14 EST from "Scott E. Fahlman"
Message-ID: <850404045222.726223@MIT-MULTICS.ARPA>
Date: 2 April 1985 23:14 est
From: Scott E. Fahlman <Fahlman at CMU-CS-C>
Subject: NIL and DEFCONSTANT [Gall: Bug Report]
I agree with Moon that it "is an error" to redefine built-in constants.
It probably is not required that an implementation stop you from doing
this, but it would be a good idea.
I think that the description on page 56 is OK as it is. First it says
that there are built-in named constants that you don't get to change.
Here it talks about such things as T and NIL. Then it says that
"constant symbols defined by Defconstant" are also treated this way, but
that they may be redefined if necessary by using Defconstant again. I
don't see anything that would imply that T and NIL are implicitly
defined by Defconstant and that they are therefore redefinable.
-- Scott
I agree with Moon also. And I agree that pg. 56 is ok too. It is pg.
69 that is a little shaky, and pg. 324 DEFINITELY states that NIL and T
are defined with DEFCONSTANT.
∂03-Apr-85 2110 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: What should CLOSE return?
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 3 Apr 85 21:08:48 PST
Posted-Date: 4 Apr 85 00:07 EST
Date: Thu, 4 Apr 85 00:05 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: Re: What should CLOSE return?
To: REM@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 3 Apr 85 03:29 EST from "Network←Server.Daemon (REM@IMSSS@SU-AI.ARPA)"
Message-ID: <850404050502.925392@MIT-MULTICS.ARPA>
Date: 3 April 1985 03:29 est
From: Network←Server.Daemon (REM@IMSSS@SU-AI.ARPA)
Return-Path: <@MIT-MULTICS.ARPA,@SU-AI.ARPA:REM@IMSSS>
Received: from SU-AI.ARPA by MIT-MULTICS.ARPA TCP; 03-Apr-1985 03:28:38-est
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-03 00:23:00 PST (=GMT-8hr)
Date: 1985 April 02 18:50:35 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132116072744.G0366
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:Gall@MIT-MULTICS.ARPA
Subject:attempt to bind constant, what should CLOSE return
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM@MIT-MC.ARPA
> Date: Thu, 21 Mar 85 00:49 EST
> From: Nick Gall <Gall@MIT-MULTICS.ARPA>
>
> From: Robert Elton Maas <REM@IMSSS.SU.EDU>
> Subject: What should CLOSE return? Closed-channel-object, or truefilename.
>
> > !topic What does CLOSE Return?
> >
> > I think it should return the STREAM it was given to close. This
> > would make it symmetric with OPEN: OPEN returns an open stream,
> > CLOSE returns a closed stream.
> That's not symmetric, that's coercive. OPEN and CLOSE are like
> matching parenthesis, one does it and the other undos it except for
> a residual side-effect. ...
>
> You're right `symmetric' is the wrong adj. But I still think CLOSE should
> return the (closed) stream. It can't (always) return the truename
> of the file associated with the stream, since not all streams are
> associated with files.
It's a matter of opinion as to what "should" be returned, and if
there's any use for the closed stream that couldn't be obtained by
retaining a pointer to the original open stream and using that pointer
after the CLOSE has been done, then I'll agree with you. But usually a
closed stream is just an open stream that has been modified in place
to be closed, in which case anyone wanting the closed stream can just
as well retain the old pointer instead of expecting that CLOSE will
return it back to you. On the other hand, if a system doesn't assign a
version number until the moment a file is closed, and if there's no
particular reason to need CLOSE to return the closed stream, then it
should return the true filename to save the user the hassle of getting
that info itself.
You still haven't said what close should return when the stream being
closed is NOT a file stream (e.g., closing a string stream). Note that
the CLOSE function is in the chapter on streams NOT the file system
interface chapter.
> To obtain the truename of a just closed file, one could write
> (truename (close x)) ; where x is bound to a file stream
> since truename will take a stream as an argument. (Unfortunately,
> the CLRM (23.1.2(5)) is only explicit about what truename does
> with an `open' stream.)
Clearly something needs to be change, either force truename to work on
closed streams, telling the true name that couldn't have been known
for sure while the file was still open, or having CLOSE return the
true filename as I suggested.
Agreed.
∂04-Apr-85 0750 RAM@CMU-CS-C.ARPA INTERN and "intern" -- the unwise choice of terminology
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Apr 85 07:50:02 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 4 Apr 85 10:43:06-EST
Date: Thu, 4 Apr 1985 10:42 EST
Message-ID: <RAM.12100476562.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Jon White <JLW@SU-AI.ARPA>
Cc: Common-Lisp@SU-AI.ARPA, Gall@MIT-MULTICS.ARPA, Moon@SCRC-STONY-BROOK.ARPA
Subject: INTERN and "intern" -- the unwise choice of terminology
In-reply-to: Msg of 3 Apr 1985 15:26-EST from Jon White <JLW at SU-AI.ARPA>
I don't think that a home-package-setting operation is well
defined, at least without some constraints. The system would
certainly get confused if you set the home package to a package that
the symbol was not accessible in, and it would be dubious to set the
home package to a package where the symbol is not present (as opposed
to inherited).
If you impose these requirements, setting the home package starts
to sound a great deal like IMPORT. I think that the proposal to have
IMPORT set the home package if there is none makes a great deal of
sense. The effect of IMPORT is really about the same as old-style
intern on a symbol. I don't really like the idea of INTERN having
obscure side-effects such as setting the home package, since it is
something that the system often does without an explicit request.
Rob
∂04-Apr-85 1104 Moon@SCRC-STONY-BROOK.ARPA INTERN and "intern" -- the unwise choice of terminology
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Apr 85 11:03:50 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 209032; Thu 4-Apr-85 13:56:10-EST
Date: Thu, 4 Apr 85 13:57 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: INTERN and "intern" -- the unwise choice of terminology
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
cc: Jon White <JLW@SU-AI.ARPA>, Common-Lisp@SU-AI.ARPA,
Gall@MIT-MULTICS.ARPA
In-Reply-To: <RAM.12100476562.BABYL@CMU-CS-C.ARPA>
Message-ID: <850404135733.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 4 Apr 1985 10:42 EST
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
I don't think that a home-package-setting operation is well
defined, at least without some constraints. The system would
certainly get confused if you set the home package to a package that
the symbol was not accessible in, and it would be dubious to set the
home package to a package where the symbol is not present (as opposed
to inherited).
If you impose these requirements, setting the home package starts
to sound a great deal like IMPORT. I think that the proposal to have
IMPORT set the home package if there is none makes a great deal of
sense. The effect of IMPORT is really about the same as old-style
intern on a symbol. I don't really like the idea of INTERN having
obscure side-effects such as setting the home package, since it is
something that the system often does without an explicit request.
This message makes sense to me.
∂04-Apr-85 1345 JLW "home-ifying" symbols
To: ram@CMU-CS-C.ARPA
CC: gall@MIT-MULTICS.ARPA, moon@SCRC-STONY-BROOK.ARPA,
common-lisp@SU-AI.ARPA
Several people, yourself included, have suggested that if a luser
sets a symbol's package cell to something random then "the system
will get very confused".
How?
The package cell seems to affect *nothing* in the system except
print, and there is nothing particularly confusing about the
fact that print will want to
1) certify either a nil or a package in that cell, and
2) output a #: prefix if it was nil.
Given the current capabilities of unintern, there seems to be no way
to avoid the so-called pathalogical situation wherein a symbol is
"homed" nowhere, yet accessible from one or more packages [shall we
call such a non-homed symbol a "bastard" since no one "owns" it?]
The problem with trying to insure the existence of a home through
side-effects in INTERN and/or IMPORT is that that doesn't address the
issue that's been galling us all along. Namely, a symbol is present
in several packages, and owned by one of them; but the luser decides
that it is homed * in the wrong package * and he wishes to change it.
How about having a set-symbol-package capablity which certifies
that the symbol is at least present in the package that it is
being "homed" in? Would that satisfy your feeling for constraints?
-- JonL --
P.S. Two uses of "certify" above mean "run a cerror if condition not met".
∂04-Apr-85 1423 RAM@CMU-CS-C.ARPA "home-ifying" symbols
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Apr 85 14:21:59 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 4 Apr 85 17:21:24-EST
Date: Thu, 4 Apr 1985 17:21 EST
Message-ID: <RAM.12100549079.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Jon White <JLW@SU-AI.ARPA>
Cc: common-lisp@SU-AI.ARPA, gall@MIT-MULTICS.ARPA, moon@SCRC-STONY-BROOK.ARPA
Subject: "home-ifying" symbols
In-reply-to: Msg of 4 Apr 1985 16:45-EST from Jon White <JLW at SU-AI.ARPA>
I would consider the system very confused if a symbol which
appears to be interned does not print readably when no package system
changes have been made between the printing and the reading. This
could happen if a symbol is not accessible in its home package.
It would be reasonable to allow setf on symbol-package with the
constraint that the new value may only be a package that the symbol is
present in. I have survived until now without this capability, but
won't object to its addition to the language, since opposing any
feature would not be in the spirit of Common Lisp.
Rob
∂04-Apr-85 1812 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: INTERN and "intern" -- the unwise choice of terminology
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 4 Apr 85 18:12:27 PST
Date: Thu, 4 Apr 85 21:06 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: Re: INTERN and "intern" -- the unwise choice of terminology
To: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 4 Apr 85 10:42 EST from "Rob MacLachlan"
Message-ID: <850405020617.786913@MIT-MULTICS.ARPA>
Date: 4 April 1985 10:42 est
From: Rob MacLachlan <RAM at CMU-CS-C>
Subject: INTERN and "intern" -- the unwise choice of terminology
I don't think that a home-package-setting operation is well
defined, at least without some constraints. The system would
certainly get confused if you set the home package to a package that
the symbol was not accessible in, and it would be dubious to set the
home package to a package where the symbol is not present (as opposed
to inherited).
If you impose these requirements, setting the home package starts
to sound a great deal like IMPORT. I think that the proposal to have
IMPORT set the home package if there is none makes a great deal of
sense. The effect of IMPORT is really about the same as old-style
intern on a symbol. I don't really like the idea of INTERN having
obscure side-effects such as setting the home package, since it is
something that the system often does without an explicit request.
Rob
I prefer this proposal to White's `setf with constraints' proposal.
∂04-Apr-85 2042 FAHLMAN@CMU-CS-C.ARPA Intern
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Apr 85 20:42:07 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 4 Apr 85 23:42:03-EST
Date: Thu, 4 Apr 1985 23:42 EST
Message-ID: <FAHLMAN.12100618376.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Intern
OK, I'd like to end this Intern nonsense before my mailbox overflows.
Could everyone live with the following:
1. Intern never messes with the Symbol-Package cell.
2. Import fills in the symbol's Symbol-Package cell with the importing
package if that cell is NIL.
3. In the next edition of the manual we fix up the description of
symbols being "interned in a package" either by flushing this whole
concept or by finding a more precise term for it.
If we do all of that, I don't think it is redundant to add a Setf for
Symbol-Package (with a check that the symbol is accessible in its home
package), but I wouldn't fight to the death if people wanted to include
this mechanism as well. I would fight an attempt to add a non-checking
Setf of Symbol-Package.
-- Scott
∂04-Apr-85 2046 FAHLMAN@CMU-CS-C.ARPA Minor correction
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Apr 85 20:46:35 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 4 Apr 85 23:46:36-EST
Date: Thu, 4 Apr 1985 23:46 EST
Message-ID: <FAHLMAN.12100619208.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Minor correction
Where I spoke of allowing SETF of Symbol-Package with a check for
accessibility of the symbol in that package, I should have said
"presence" of the symbol.
-- Scott
∂04-Apr-85 2056 FAHLMAN@CMU-CS-C.ARPA NIL and DEFCONSTANT [Gall: Bug Report]
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Apr 85 20:56:47 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 4 Apr 85 23:56:22-EST
Date: Thu, 4 Apr 1985 23:56 EST
Message-ID: <FAHLMAN.12100620981.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Nick Gall <Gall@MIT-MULTICS.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: NIL and DEFCONSTANT [Gall: Bug Report]
In-reply-to: Msg of 3 Apr 1985 23:52-EST from Nick Gall <Gall at MIT-MULTICS.ARPA>
I agree with Moon also. And I agree that pg. 56 is ok too. It is pg.
69 that is a little shaky, and pg. 324 DEFINITELY states that NIL and T
are defined with DEFCONSTANT.
OK, we all agree that it is an error to redefine built-in constants,
whether or not we think of them as having been created by defconstant.
The manual should be made consistent on this point.
-- Scott
∂05-Apr-85 1106 Moon@SCRC-STONY-BROOK.ARPA Intern
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Apr 85 11:06:46 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 209748; Fri 5-Apr-85 14:04:36-EST
Date: Fri, 5 Apr 85 14:06 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Intern
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12100618376.BABYL@CMU-CS-C.ARPA>
Message-ID: <850405140606.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 4 Apr 1985 23:42 EST
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
OK, I'd like to end this Intern nonsense before my mailbox overflows.
Could everyone live with the following:
1. Intern never messes with the Symbol-Package cell.
2. Import fills in the symbol's Symbol-Package cell with the importing
package if that cell is NIL.
3. In the next edition of the manual we fix up the description of
symbols being "interned in a package" either by flushing this whole
concept or by finding a more precise term for it.
If we do all of that, I don't think it is redundant to add a Setf for
Symbol-Package (with a check that the symbol is accessible in its home
package), but I wouldn't fight to the death if people wanted to include
this mechanism as well. I would fight an attempt to add a non-checking
Setf of Symbol-Package.
This is fine with me.
Hey, I don't even have to make any changes in my implementation to conform
to this clarified specification!
∂05-Apr-85 1227 REM%IMSSS.#Pup@SU-SCORE.ARPA Any complete CL implementations??
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Apr 85 12:27:01 PST
Received: from IMSSS by Score with Pup; Fri 5 Apr 85 12:26:35-PST
Date: 5 Apr 1985 1224-PST
From: Rem@IMSSS
Subject: Any complete CL implementations??
To: COMMON-LISP%SU-AI@SCORE
At this time, has anybody completely 100% implemented Common LISP
on any machine at all? I mean every single function in the manual
without exception, every single feature in the manual (either as
documented in manual or as amended more recently for next edition)
for each such function, and every general capability such as all
datatypes and closures of lexical variabls etc. etc.?
If not, what is the best anybody has done to date? Would anybody with
at least 50% of Common LISP (by some reasonable way of measuring)
please send me a brief description of their implementation (CPU and
operating system, % of CL implemented, list of major capabilities
not implemented yet) for my curiosity?
SCORE's mailbridge doesn't put correct return address, so reply via any of:
Local on IMSSS: REM
Anywhere on SU-NET with PUPMAIL: REM@IMSSS
Anywhere on Arpanet: REM%IMSSS@SCORE
Anywhere else on TCP/IP Arpa-Internet: REM@MIT-MC.ARPA (forwards to IMSSS)
-------
∂05-Apr-85 1740 @SU-SCORE.ARPA:HEDRICK@RUTGERS.ARPA Re: Any complete CL implementations??
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Apr 85 17:40:48 PST
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 5 Apr 85 17:40:02-PST
Date: 5 Apr 85 20:39:53 EST
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: Any complete CL implementations??
To: rem%imsss@SU-SCORE.ARPA
cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA
In-Reply-To: Message from "Rem@IMSSS" of 5 Apr 85 15:24:00 EST
It is very hard to evaluation how much is finished, as there is no
evaluation suite. We have an implementation for TOPS-20, based on
the CMU Spice Lisp implementation. Here are the known bugs and
omissions, but it is certainly possible that there are things we
don't know about. This prefixed by * will be fixed fairly soon.
*Supposedly the same args can be used for &rest and &key. This fails
(in interpreted code only; the compiler can handle this).
Complex numbers are not implemented.
When doing file-position, and maybe clrbfo and clrbfi, maybe
we should clear lookahead and other status.
Fix GRINDEF of macros to reproduce the DEFMACRO format,
instead of using the undocumented MACRO format.
Fix ` to produce a macro instead of expanding at read time.
That way GRINDEF can print them properly.
It should be possible to continue after a break initiated by ↑B.
Printing of circular objects is not implemented.
INSPECT is not really implemented.
RANDOM don't seem very hot: There seems to be too many repeated values.
Maybe this is word-size dependent or something.
Use | | instead of slashification in printing atom names.
Missing :copier option for defstruct
Missing &environment option for defmacro
In Arith, function that could benefit from handcoding:
dramatic benefit: floor, ceiling, round, mod, logcount
some benefit: rem, ffloor, fceiling, ftruncate, fround
RATIONALIZE is currently the same as RATIONAL.
Compiler can't handle closures. Programs will work, but functions
requiring closures will be interpreted.
Missing DEFTYPE
*READ barfs when CL:CLISP is typed in.
*TRUNCATE doesn't return correct remainders for some values. Eg, -0.7
and -0.3.
-------
∂07-Apr-85 2026 FAHLMAN@CMU-CS-C.ARPA Any complete CL implementations??
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 Apr 85 20:26:39 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 7 Apr 85 23:26:32-EST
Date: Sun, 7 Apr 1985 23:26 EST
Message-ID: <FAHLMAN.12101401976.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Rem @ MIT-MC.ARPA
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Any complete CL implementations??
In-reply-to: Msg of 5 Apr 1985 15:24-EST from Rem at IMSSS
Our CMU version of Common Lisp on the Perq is essentially complete
except for complex numbers. These have now been coded, and will
probably be added to our system this week. By "essentially complete", I
mean that nothing big is missing, though from time to time we discover
that something has slipped through the cracks. CCASE and CTYPECASE are
still among the missing, I think. I cannot claim that our system is
believed to be a 100% complete and correct implementation. A number of
bugs have been discovered and not yet fixed, and the whole system is in
need of a systematic testing.
A number of companies have started with our code and have had a lot more
manpower for testing and fixing, so I wouldn't be surprised if a number
of implementations are as complete as ours and a good deal more
polished. There is not much reason for anyone following this route to
end up with a less-than-complete Common Lisp -- once the basics are up,
we can hand them the code for the rest. It is usually the
implementations that try to bend some existing Lisp into a Common Lisp
that end up stuck at 90% compatibility.
-- Scott
∂08-Apr-85 0723 RAM@CMU-CS-C.ARPA Probe-File and proposed extension.
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 07:23:33 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 8 Apr 85 10:23:37-EST
Date: Mon, 8 Apr 1985 10:23 EST
Message-ID: <RAM.12101521600.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Probe-File and proposed extension.
Query:
Should Probe-File never signal an error, even if it is given a
namestring which is malformed?
Proposal:
There needs to be some way to determine whether a file name is
legal for output. I brought this issue up once before on this mailing
list, but I think the discussion died. I am bringing it up again
because we need something of the sort in Spice Lisp, so I am going to
implement it. My proposed solution is the following: Probe-File
should take a direction argument, which defaults to :input. The
semantics of Probe-File would be to return the pathname which would be
used if the file was opened in that direction, and to return NIL if
the open would fail. Secondary query: Should the direction argument
be a keyword or an optional? I favor an optional, since I can't think
of any other arguments that want to be added to Probe-File.
Rob
∂08-Apr-85 0821 gls%AQUINAS.TMC@Think NIL and DEFCONSTANT [Gall: Bug Report]
Received: from [10.4.0.6] by SU-AI.ARPA with TCP; 8 Apr 85 08:16:26 PST
Received: by Think.ARPA with CHAOS id AA14362; Mon, 8 Apr 85 11:13:45 est
Date: Mon, 8 Apr 85 11:16 EST
From: Guy Steele <gls%AQUINAS.TMC@Think>
Subject: NIL and DEFCONSTANT [Gall: Bug Report]
To: Gall%MULTICS.MIT@Think
Cc: common-lisp@SU-AI.ARPA, gls%AQUINAS.TMC@Think
In-Reply-To: <FAHLMAN.12100620981.BABYL@CMU-CS-C.ARPA>
Maybe a right attitude to take is that it is an error
to execute any compiled code that refers to a DEFCONSTANT'ed
name that has been re-DEFCONSTANT'ed to a different (non-EQL?)
value since the code was compiled.
That would say that it is okay to (DEFCONSTANT T 43), but then
you had better not execute any system code that refers to T.
But the evaluator probably refers to T, so in practice you had
simply better not do it.
--Guy
∂08-Apr-85 1134 Moon@SCRC-STONY-BROOK.ARPA Probe-File and proposed extension.
Received: from [18.26.0.206] by SU-AI.ARPA with TCP; 8 Apr 85 11:34:38 PST
Received: from WAIKATO by ZERMATT via CHAOS with CHAOS-MAIL id 2202; Mon 8-Apr-85 14:32:39-EST
Received: from SCRC-EUPHRATES by WAIKATO via CHAOS with CHAOS-MAIL id 91565; Mon 8-Apr-85 14:32:07-EST
Date: Mon, 8 Apr 85 14:33 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Probe-File and proposed extension.
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12101521600.BABYL@CMU-CS-C.ARPA>
Message-ID: <850408143305.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 8 Apr 1985 10:23 EST
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Query:
Should Probe-File never signal an error, even if it is given a
namestring which is malformed?
Proposal:
There needs to be some way to determine whether a file name is
legal for output. I brought this issue up once before on this mailing
list, but I think the discussion died. I am bringing it up again
because we need something of the sort in Spice Lisp, so I am going to
implement it. My proposed solution is the following: Probe-File
should take a direction argument, which defaults to :input. The
semantics of Probe-File would be to return the pathname which would be
used if the file was opened in that direction, and to return NIL if
the open would fail.
What's wrong with calling OPEN and handling the error when it fails? Since
I don't understand the desired application, I don't know whether my question
makes sense.
"Common Lisp does not have a standard way to handle errors" is not an acceptable
answer. It should get one.
Secondary query: Should the direction argument
be a keyword or an optional? I favor an optional, since I can't think
of any other arguments that want to be added to Probe-File.
I can think of two other arguments right off the bat; make it a keyword.
∂08-Apr-85 1156 RAM@CMU-CS-C.ARPA Probe-File and proposed extension.
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 11:56:07 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 8 Apr 85 14:55:43-EST
Date: Mon, 8 Apr 1985 14:55 EST
Message-ID: <RAM.12101571128.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Probe-File and proposed extension.
In-reply-to: Msg of 8 Apr 1985 14:33-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
There are circumstances where being able to validate a filename as
potentially writable without actually writing that file would be
useful.
The specific problem I want to solve involves the the "Visit File"
command in Hemlock. If you visit a file that exists, you read the
file, and the pathname associated with the buffer becomes the truename
of the file; no problem there. The question is what do you do if
Probe-File of the filename is false? Does this mean that the file
simply doesn't exist, or does it mean that the filename is somehow
broken? An example of a broken filename would be one with a
nonexistant directory or device.
If the filename is broken it would be useful to be able to
tell the user this when he visits the file, rather than getting some
error when he tries to save it. It is also useful to be able to get
the name of the file that you expect to be created, since then you can
set the buffer pathname to that, rather than leaving it a relative
pathname until the file is actually created.
Rob
∂08-Apr-85 1208 greek@DEC-HUDSON More on PROBE-FILE.
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 12:07:56 PST
Date: Mon, 08 Apr 85 15:05:05 EST
From: greek@DEC-HUDSON
Subject: More on PROBE-FILE.
To: common-lisp@su-ai
Just got Dave Moon's message about Rob's proposal for PROBE-FILE.
Although I certainly agree that Common LISP needs an error
handling facility, I don't want to have to use it to investigate
whether or not a file exists. That's a basic file operation for
which we've already attempted to account. Let's fix up the way
we do it, not just punt it.
- Paul
∂08-Apr-85 1208 greek@DEC-HUDSON PROBE-FILE
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 12:08:25 PST
Date: Mon, 08 Apr 85 15:02:22 EST
From: greek@DEC-HUDSON
Subject: PROBE-FILE
To: common-lisp@su-ai
Rob's proposal makes sense. A few comments:
1. Yup, use a keyword, namely :DIRECTION.
2. If we believe in :DIRECTION for PROBE-FILE, then we have to admit
that :DIRECTION :PROBE makes no sense for OPEN, because probing
is orthogonal to direction. I suggest we either add :PROBE T
as another keyword to OPEN, or, better yet, remove the feature
from OPEN.
3. PROBE-FILE needs to tell me more. I want to know if I can't get
at the file because:
a) the file spec is bad.
b) the device doesn't exist.
c) the directory doesn't exist.
d) I don't have sufficient access privilege.
e) etc., etc.
The basic need addressed by Rob is a real one: Is this file spec good,
can I get to the file, and what can I do to it (read, write, etc).
- Paul
∂08-Apr-85 1222 RAM@CMU-CS-C.ARPA PROBE-FILE
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 12:22:46 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 8 Apr 85 15:22:27-EST
Date: Mon, 8 Apr 1985 15:22 EST
Message-ID: <RAM.12101576001.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: greek@DEC-HUDSON.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: PROBE-FILE
In-reply-to: Msg of 8 Apr 1985 15:02-EST from greek at DEC-HUDSON
A while back when bogosity in the file system chapter was being
discussed on this list, Moon proposed that :direction :probe be
flushed, and everyone seemed to agree.
Rob
∂08-Apr-85 1234 RAM@CMU-CS-C.ARPA PROBE-FILE
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 12:33:59 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 8 Apr 85 15:33:19-EST
Date: Mon, 8 Apr 1985 15:33 EST
Message-ID: <RAM.12101577955.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: greek@DEC-HUDSON.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: PROBE-FILE
In-reply-to: Msg of 8 Apr 1985 15:02-EST from greek at DEC-HUDSON
The issue of how to get back more information about what is wrong
with a file was where we got bogged down before. I think that error
systems are the called for when you start to consider that sort of
issue. Any enumeration of all the things that can go wrong with
writing a file will also probably be hopelessly implementation
dependent. Unless you can come up with a simple, highly esthetic
proposal, I think we should stick with NIL for failure.
I suppose we could return an error-message string as a second
value, but anything along those lines seems like a sort of half-way
measure to me.
Rob
∂08-Apr-85 1345 REM@IMSSS error-protected OPEN isn't a good way to fake a probe
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-08 13:38:39 PST (=GMT-8hr)
Date: 1985 April 08 13:37:02 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132123230137.G0465
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:Moon@SCRC-STONY-BROOK.ARPA
CC:COMMON-LISP@SU-AI.ARPA,RAM@CMU-CS-C.ARPA
Subject: error-protected OPEN isn't a good way to fake a probe
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM@MIT-MC.ARPA
|Date: Mon, 8 Apr 85 14:33 EST
|From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
|Subject: Probe-File and proposed extension.
|To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
|cc: common-lisp@SU-AI.ARPA
| There needs to be some way to determine whether a file name is
| legal for output.
|What's wrong with calling OPEN and handling the error when it fails? Since
|I don't understand the desired application, I don't know whether my question
|makes sense.
That's unacceptable. Suppose you have an application program that
wants to write two output files (for example, binary and listing
output from assembler or compiler) under luser-control (one or both
names might be wrong, and this is common enough to protect against in
a clean way). The program wants to check both files for validity
before opening either. If you handle error when OPEN fails, then if
the first name is good and the second bad, by the time you find out
the second is bad you have already made the mistake of starting to
create the first file when the process can't finish and the file must
then be garbage. It is therefore necessary to probe both files before
opening either (or at least probe all but one and then
error-protected-OPEN the remaining; but probing all of them is cleaner).
∂08-Apr-85 1446 Moon@SCRC-STONY-BROOK.ARPA Probe-File and proposed extension.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 14:45:43 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211090; Mon 8-Apr-85 17:00:45-EST
Date: Mon, 8 Apr 85 17:38 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Probe-File and proposed extension.
To: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>,
Rob MacLachlan <RAM@CMU-CS-C.ARPA>, greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850408143305.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<RAM.12101571128.BABYL@CMU-CS-C.ARPA>,
The message of 8 Apr 85 15:02-EST from greek at DEC-HUDSON,
The message of 8 Apr 85 15:05-EST from greek at DEC-HUDSON,
<RAM.12101576001.BABYL@CMU-CS-C.ARPA>,
<RAM.12101577955.BABYL@CMU-CS-C.ARPA>
Message-ID: <850408173849.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 8 Apr 85 14:33 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: Mon, 8 Apr 1985 10:23 EST
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Query:
Should Probe-File never signal an error, even if it is given a
namestring which is malformed?
No, it should signal lots of errors.
Proposal:
There needs to be some way to determine whether a file name is
legal for output. I brought this issue up once before on this mailing
list, but I think the discussion died. I am bringing it up again
because we need something of the sort in Spice Lisp, so I am going to
implement it. My proposed solution is the following: Probe-File
should take a direction argument, which defaults to :input. The
semantics of Probe-File would be to return the pathname which would be
used if the file was opened in that direction, and to return NIL if
the open would fail.
What's wrong with calling OPEN and handling the error when it fails? Since
I don't understand the desired application, I don't know whether my question
makes sense.
Answered below.
"Common Lisp does not have a standard way to handle errors" is not an acceptable
answer. It should get one.
Date: Mon, 8 Apr 1985 14:55 EST
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
There are circumstances where being able to validate a filename as
potentially writable without actually writing that file would be
useful.
The specific problem I want to solve involves the the "Visit File"
command in Hemlock. If you visit a file that exists, you read the
file, and the pathname associated with the buffer becomes the truename
of the file; no problem there. The question is what do you do if
Probe-File of the filename is false? Does this mean that the file
simply doesn't exist, or does it mean that the filename is somehow
broken? An example of a broken filename would be one with a
nonexistant directory or device.
If the filename is broken it would be useful to be able to
tell the user this when he visits the file, rather than getting some
error when he tries to save it.
I see. In our implementation, the ambiguous phrase (actually lifted
from the old Lisp Machine manual) "if there is no file named" in the
documentation of PROBE-FILE is interpreted to mean that only a
file-not-found error returns NIL; any other error, such as
directory-not-found, host-not-up, name-too-long, etc. is signalled in
the normal way. Thus PROBE-FILE serves as a test for whether you'll be
able to write the file, assuming you have access to write, the host is
still up when you try to write, the disk hasn't filled up by then, etc.
Another way of saying this is that PROBE-FILE returns NIL without
signalling an error if it would be possible for the file to exist at
some future time (well, this is still ambiguous, after all someone could
create a directory, rename a device, buy a new computer, or whatever).
I think this means that our PROBE-FILE does everything your Visit File
command needs.
But I see that others could interpret the Common Lisp manual differently.
I suppose the manual has to be ambiguous because anything more specific
might be unimplementable on some file system! I think it would be better
for you to fix your PROBE-FILE (to signal errors other than file-not-found)
than to change its arguments to make it optional to do so.
It is also useful to be able to get
the name of the file that you expect to be created, since then you can
set the buffer pathname to that, rather than leaving it a relative
pathname until the file is actually created.
Agreed. Our understanding is that MERGE-PATHNAMES is how relative
pathnames get expanded. The manual doesn't say anything about relative
pathnames, but I don't see how anything but MERGE-PATHNAMES could expand
them, since they have to be relative to some default. But maybe you
mean something different by "relative pathnames" than I; after all, the
manual doesn't define the term. I mean pathnames with relative directory
names, which start at some default directory in the tree of directories,
rather than starting at the root. In Unix, all pathnames that don't start
with a slash.
Date: Mon, 08 Apr 85 15:02:22 EST
From: greek@DEC-HUDSON
....
3. PROBE-FILE needs to tell me more. I want to know if I can't get
at the file because:
a) the file spec is bad.
b) the device doesn't exist.
c) the directory doesn't exist.
d) I don't have sufficient access privilege.
e) etc., etc.
The basic need addressed by Rob is a real one: Is this file spec good,
can I get to the file, and what can I do to it (read, write, etc).
Agreed, but see below.
Although I certainly agree that Common LISP needs an error
handling facility, I don't want to have to use it to investigate
whether or not a file exists.
Why not?
That's a basic file operation for which we've already attempted to
account. Let's fix up the way we do it, not just punt it.
Why is using the error-handling facility considered punting?
Date: Mon, 8 Apr 1985 15:22 EST
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
A while back when bogosity in the file system chapter was being
discussed on this list, Moon proposed that :direction :probe be
flushed, and everyone seemed to agree.
I still think so. It should exist only as an internal implementation
detail of PROBE-FILE in some implementations.
Date: Mon, 8 Apr 1985 15:33 EST
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
The issue of how to get back more information about what is wrong
with a file was where we got bogged down before. I think that error
systems are the called for when you start to consider that sort of
issue. Any enumeration of all the things that can go wrong with
writing a file will also probably be hopelessly implementation
dependent.
I agree. Look at Greek's list above, for example, especially item (e).
Unless you can come up with a simple, highly esthetic
proposal, I think we should stick with NIL for failure.
I suppose we could return an error-message string as a second
value, but anything along those lines seems like a sort of half-way
measure to me.
I don't think a string is what is going to be wanted in many cases, since
it is not program-understandable.
∂08-Apr-85 1452 Moon@SCRC-STONY-BROOK.ARPA error-protected OPEN isn't a good way to fake a probe
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 14:52:30 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211097; Mon 8-Apr-85 17:08:39-EST
Date: Mon, 8 Apr 85 17:46 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: error-protected OPEN isn't a good way to fake a probe
To: REM@MIT-MC.ARPA
cc: COMMON-LISP@SU-AI.ARPA, RAM@CMU-CS-C.ARPA
In-Reply-To: SU-IMSSS.REM.A132123230137.G0465
Message-ID: <850408174655.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
|Date: Mon, 8 Apr 85 14:33 EST
|From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
|Subject: Probe-File and proposed extension.
|To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
|cc: common-lisp@SU-AI.ARPA
| There needs to be some way to determine whether a file name is
| legal for output.
|What's wrong with calling OPEN and handling the error when it fails? Since
|I don't understand the desired application, I don't know whether my question
|makes sense.
That's unacceptable. Suppose you have an application program that
wants to write two output files (for example, binary and listing
output from assembler or compiler) under luser-control (one or both
names might be wrong, and this is common enough to protect against in
a clean way). The program wants to check both files for validity
before opening either. If you handle error when OPEN fails, then if
the first name is good and the second bad, by the time you find out
the second is bad you have already made the mistake of starting to
create the first file when the process can't finish and the file must
then be garbage. It is therefore necessary to probe both files before
opening either (or at least probe all but one and then
error-protected-OPEN the remaining; but probing all of them is cleaner).
This is what the :ABORT argument to CLOSE is for.
∂08-Apr-85 1531 RAM@CMU-CS-C.ARPA Probe-File and proposed extension.
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 15:30:23 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 8 Apr 85 18:29:59-EST
Date: Mon, 8 Apr 1985 18:29 EST
Message-ID: <RAM.12101610106.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA, greek@DEC-HUDSON.ARPA
Subject: Probe-File and proposed extension.
In-reply-to: Msg of 8 Apr 1985 17:38-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
The point about relative pathnames is the following: When you
actually write a file, Open resolves any relative pathname down to an
absolute pathname. Any implementation that allows writing relative
pathnames must have some way to map the relative pathname to an
absolute pathname. This mapping is not necessarily the same as merge
pathnames, and in any case, there is no way in Common Lisp to
determine what the defaults are.
In Spice Lisp, when you open a file for write, Open first looks
for any file with that name on the default search list, and if found,
overwrites it, otherwise it creates a file in the current directory.
I will argue that this is the right semantics in our implementation,
and it is clearly implementation dependent.
Regardeless of the error issue, it would be useful to be able to
default a pathname for output in this fashion.
As for the error issue, Spice Lisp currently does exactly what you
suggest. A user complained that this was not what the manual said it
should do. I tried both the Dec-20 Clisp and the Kyoto Common Lisp
implementations, and they both refused to signal errors, no matter
what garbage you gave them. I decided at this point that the issue
was unclear, but that the Spice Lisp implementation was probably
wrong.
Rob
∂08-Apr-85 1719 card.pa@Xerox.ARPA Re: Arg count checking
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 17:16:40 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 APR 85 17:07:23 PST
Date: 8 Apr 85 17:06 PST
From: card.pa@Xerox.ARPA
Subject: Re: Arg count checking
In-reply-to: masinter.pa's message of 1 Apr 85 01:00 PST
To: masinter.pa@Xerox.ARPA
cc: bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA
Larry's message had an idea that coud be developed to handle both what I
take to be the motivations of arg count checking and the motivations for
optional arguments and more.
1. I remember that programming in Stanford Lisp 1.6, the mismatched
number of argument was one of the most effective checks for getting out
nuissance bugs quickly, especially the kind that comes where you change
the arguments of the callee and miss some occurrences of calls to it.
2. The main offsetting advantage from giving this up in Interlisp-D
seems to be that for functions with complicated arguments that are
infrequently used. A simple calling sequnce is available for simple
calls, more complicated calls for complicated situations. But there
would seem to be be more graceful (from the point of view of the program
reflecting the user's intentions) methods of achieving this.
3. It is certainly eaiser for the programmer to call
(NSPRINT 'MYPRINTER)
than to have to write
(NSPRINT 'MYPRINTER NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL).
Thus optional arguments are handy. But they are not really handy enough
because
(NSPRINT 'MYPRINTER NIL NIL NIL NIL NIL NIL NIL NIL T)
is still required to request stapling on the printed output. This call
is not programmable without reference to the manual or a system aid such
as ?=. It is a likely location for error (miscouting the arguments) and
it is not readable by someone looking over the code.
If (1) arguments could be addressed by argument name and (2) could be
optional, then such problems would disappear. A notation that would
stay within the Interlisp tradition, would be to pattern it after
DLAMBDA declarations in DECL. Thus OPTIONAL would become a property of
arguments in the same way as FIXP.
DEFINEQ
((NSPRINT
(LAMBDA (PRINTER
(FILE.NAME OPTIONAL)
(DOCUMENT.NAME OPTIONAL)
(DOCUMENT.CREATION.DATE OPTIONAL)
(RECIPIENT.NAME OPTIONAL)
(#COPIES OPTIONAL)
(MEDIUM OPTIONAL)
(PRIORITY OPTIONAL)
(STAPLE? OPTIONAL)
(TWO.SIDED OPTIONAL)))))
implements a function where the first argument PRINTER is mandatory and
the remaining are all optional.
The function could be called with the syntax
(NSPRINT 'MYPRINTER STAPLE?=T)
or perhaps a prefix syntax syntax such as
(NSPRINT 'MYPRINTER (& STAPLE? T))
or
(NSPRINT 'MYPRINTER / STAPLE? T) .
ANY argument ought to be callable this way. (A more elegant proposal
might even be able to encompass the current syntax of (FOR X IN L
SUCHTHAT ...) as an instance, thus serving as a unifying abstraction for
Interlisp syntax). Of course, the OPTIONAL property would be made to
fit into DECL as just one more property:
(DLAMBDA ((A LISTP SPECIAL )
(B FIXP LOCAL OPTIONAL)) . . . ).
Arguments described by name and optional arguments would probably be a
slight bit slower than fixed arguments, but (1) this would be well worth
the convenience and readability is most cases (e.g. NSPRINT). (2) The
fixed argument called by place would still be about as the same speed as
they were, probably, and (3) Fast versions of complicated argument calls
where small gains in speed were very important would be programmed in
fast versions, as at present (FRPLACA).
Thus both bug detection and optional argument calling flexibility can be
had within a unified framework that generalizes both. It would seem
that one can car one's cake and cons it too.
∂08-Apr-85 1736 KMP@SCRC-STONY-BROOK.ARPA PROBE-FILE
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 17:35:47 PST
Received: from SCRC-RIO-DE-JANEIRO by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211220; Mon 8-Apr-85 19:42:56-EST
Date: Mon, 8 Apr 85 20:19 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: PROBE-FILE
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA, Moon@SCRC-STONY-BROOK.ARPA
In-Reply-To: The message of 8 Apr 85 15:02-EST from greek at DEC-HUDSON
Message-ID: <850408201917.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Mon, 08 Apr 85 15:02:22 EST
From: greek@DEC-HUDSON
Rob's proposal makes sense. A few comments:
...
3. PROBE-FILE needs to tell me more. I want to know if I can't get
at the file because:
a) the file spec is bad.
b) the device doesn't exist.
c) the directory doesn't exist.
d) I don't have sufficient access privilege.
e) etc., etc.
The basic need addressed by Rob is a real one: Is this file spec good,
can I get to the file, and what can I do to it (read, write, etc).
It is precisely because of this need to return a multitude of kinds of
information that the Lisp Machine has gone away from having more functions
to do this kind of investigation and toward using errors to convey this
information. In the Lisp Machine's not-really-new-any-more "new error system",
failure is flavorized so that a lot of kinds of information can be extracted
depending on what the caller needs to know. This also has the important
advantage that users who don't realize they need to detect odd situations
will have their code stopped cold in its tracks rather than having it
stumble on and notice a problem only later.
For example, in Lisp Machine lisp, if you want to know if the failure was
due to device doesn't exist, you can take the error object and do:
(TYPEP error-object 'FS:DEVICE-NOT-FOUND)
or if you want to know if a directory was not found, you do:
(TYPEP error-object 'FS:DIRECTORY-NOT-FOUND)
Or if you want more general information you can do:
(TYPEP error-object 'FS:FILE-LOOKUP-ERROR)
which will find both FS:DEVICE-NOT-FOUND errors and FS:DIRECTORY-NOT-FOUND
errors. This allows error signallers to be quite exact about the error
that occurred (by mixing in as many error types as are known to be relevant)
and still have a fair chance that the handler will do something reasonable
(by allowing it to look for more specific condition types than are actually
signal.
If you compare this to what you're asking for PROBE-FILE, you quickly
realize that there is no obvious way to stop a huge explosion of functions
named things like:
(PROBE-FILE-RETURNING-NIL-FOR-BAD-PATHNAME ...)
(PROBE-FILE-RETURNING-NIL-FOR-BAD-DEVICE-BUT-ERRING-ON-OTHER-PATHNAMES ...)
...
or a huge explosion of keywords as in:
(PROBE-FILE ... :ALLOW-ERROR-IF '(:BAD-DEVICE :BAD-DIRECTORY))
or a huge explosion of return values as in:
(PROBE-FILE pathname) => pathname-or-NIL,
device-not-found-p,
device-not-valid-p,
directory-not-found-p,
...
or a huge explosion of keywords in return values such as
(PROBE-FILE pathname) => pathname-or-NIL, reason-keyword (one of
:DEVICE-NOT-FOUND, :DIRECTORY-NOT-AVAILABLE,...)
etc. The problem with these situations is that you are then locked into a
bottomless pit of having to make non-general extensions to the language
every time a new situation comes up.
In the Lisp Machine case, the definition of PROBEF is fairly simple. It
returns a pathname if the probe code succeeds and the file was there,
NIL if the probe code succeeds but no file was there, and errs if the probe
code encounters a problem. How those problems may occur is something
which users know is device dependent and subject to change as new devices
are added or devices change their behavior. The really nice point is that
flavors were designed to accomodate both the process of change and some
sense of ambiguity in terms of what the error type is ("Is it a string error
or a file error? hmm. Guess i'll make a new flavor file-string-error so
that people watching for either situation can handle it.")
So I really think this is something to be relegated to error handling.
Although there's been little discussion on the error handling mailing list,
I did get what I think is a fairly workable proposal out before discussion
died down, so don't worry that we're just talking pipe dreams here.
That's about all I have to say on the subject for now. Over the past
several years using the LispM file system, I've been extremely pleased
with how little I had to think about the target file system because of
the nice abstractions upon which it's based. So my proxy basically goes
to Moon for any further discussion on this subject. Just wanted to say
something supportive since on sheer volume of mail it might have
appeared he wasn't being believed.
∂08-Apr-85 1937 FAHLMAN@CMU-CS-C.ARPA NIL and DEFCONSTANT [Gall: Bug Report]
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 19:37:30 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 8 Apr 85 22:37:30-EST
Date: Mon, 8 Apr 1985 22:37 EST
Message-ID: <FAHLMAN.12101655193.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: NIL and DEFCONSTANT [Gall: Bug Report]
Response to Steele:
Maybe a right attitude to take is that it is an error
to execute any compiled code that refers to a DEFCONSTANT'ed
name that has been re-DEFCONSTANT'ed to a different (non-EQL?)
value since the code was compiled.
Yeah, that seems reasonable. We want to be able to change the value of
a constant if, for example, we notice a typo, but once something has
been compiled that uses that constant, it is unpredictable which value
you get if you then change the constant.
That would say that it is okay to (DEFCONSTANT T 43), but then
you had better not execute any system code that refers to T.
But the evaluator probably refers to T, so in practice you had
simply better not do it.
This looks like trouble to me. I don't think we'd better tell the users
that this is legal but that they'd probably better not do it in
practice. Unlike us high-powered language designers, mere users are
likely to be confused by this. Maybe we'd just better tell them that it
is erroneous, wrongheaded, evil, and uncool to do this, and that if they
persist in this practice Father Lisp won't bring them any parentheses
when they hang out their bit buckets on Flag Day.
-- Scott
∂08-Apr-85 1946 fateman%ucbdali@Berkeley Re: Arg count checking
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 19:46:22 PST
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.45)
id AA05969; Mon, 8 Apr 85 19:45:24 pst
Received: by ucbdali.ARPA (4.24/4.42)
id AA05239; Mon, 8 Apr 85 19:46:33 pst
Date: Mon, 8 Apr 85 19:46:33 pst
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8504090346.AA05239@ucbdali.ARPA>
To: card.pa@Xerox.ARPA, masinter.pa@Xerox.ARPA
Subject: Re: Arg count checking
Cc: bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA
A heretical suggestion:
(let ((staple? t)) (nsprint 'mprinter)).
Using dynamic scope and global variables has been widely used in
Interlisp and other systems to great advantage (and disadvantage).
Setting up your default nsprint environment by setq's and then locally
overriding is handy, though I suppose this is possible to do by
initializing the optional arguments according to whether global variables
of the same name are bound etc.
∂09-Apr-85 0100 hplabs!perdue%hplabs.csnet@csnet-relay.arpa Compilation and package system
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 9 Apr 85 00:59:52 PST
Received: from hplabs by csnet-relay.csnet id ad14103; 9 Apr 85 3:42 EST
Received: by HP-VENUS id AA23590; Mon, 8 Apr 85 18:04:43 pst
Message-Id: <8504090204.AA23590@HP-VENUS>
Date: 8-Apr-85 18:03:48
To: Common-lisp@su-ai.ARPA
Subject: Compilation and package system
From: perdue%hplabs.csnet@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
It is surprising to me that there has not been discussion of
the problems of compiling when there is a package system.
The specific problem I have in mind is in the handling of
symbols that are referred to in the input text without a package
qualifier.
The user of a Common LISP implementation sees the problem as a
difference between the behavior of a module (file) loaded in its
interpretive form and loaded in its compiled form. Specifically,
references to symbols will in some cases be resolved differently
depending on whether or not the file was compiled before being loaded.
The source of the problem is that LISP compilers use READ to get
forms to compile and READ loses all information about whether a symbol
was specified with a package qualifier and whether a single or double
colon. If the file has an IN-PACKAGE at the beginning it is only
pathological cases that cause problems, but if the file does not,
needed information has clearly been lost.
The CLM specifies that loading a compiled file shall be equivalent
to loading an interpretive file, but the packages of symbols in
a compiled file have in effect been DETERMINED AT COMPILE TIME,
and load-time binding can only be faked.
Various heuristics are used by implementations to try to do more
or less the right thing. For example, any symbol available without
name qualification when read can be assumed to have been named
without a package qualifier. At loadtime the reference can be
resolved as though it had no qualifier. But the knowledge of
whether it was actually written with qualification has been lost.
If the module (file) is loaded with a current package different than
the current package when it was compiled, loading of the compiled
version will not necessarily result in references to the same symbols
as loading the interpretive version of the module.
-------
∂09-Apr-85 0448 REM@IMSSS I agree, but manual should tell LUSERs why
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-09 04:46:51 PST (=GMT-8hr)
Date: 1985 April 09 02:54:05 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132124131673.G0390
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:Fahlman@CMU-CS-C.ARPA
CC:common-lisp@SU-AI.ARPA
Subject: I agree, but manual should tell LUSERs why
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM@MIT-MC.ARPA
|Date: Mon, 8 Apr 1985 22:37 EST
|From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
|Subject: NIL and DEFCONSTANT [Gall: Bug Report]
|
| Maybe a right attitude to take is that it is an error
| to execute any compiled code that refers to a DEFCONSTANT'ed
| name that has been re-DEFCONSTANT'ed to a different (non-EQL?)
| value since the code was compiled.
|
|Yeah, that seems reasonable. We want to be able to change the value of
|a constant if, for example, we notice a typo, but once something has
|been compiled that uses that constant, it is unpredictable which value
|you get if you then change the constant.
I agree. But more than just saying "it is an error to use code that
has been compiled with one value of a constant in an environment where
that constant now has a different value", we should explain what seems
obvious to us so LUSERs who can't see the obvious can be shown the
obvious and then see it themselves. (This is the sort of thing that
isn't machine-dependent, the same problem would happen on virtually
any system we imagine, thus we CAN say something more than the
mysterious cop-out "it is an error to ...".) We could say something
like "if code is compiled with the constant having one value, but then
the constant is redefined and the previously-compiled code is run, it
will probably use the old value instead of the new value. Accordingly,
it is an error to continue to run the previously-compiled code after
the constant has been redefined, and it is an error to redefine any
commonly-used system constant unless one plans to recompile the whole
LISP system immediately thereafter. It is an error to redefine T or
NIL in any case of course."
|Maybe we'd just better tell them that it is erroneous, wrongheaded,
|evil, and uncool to do this, and that if they persist in this practice
|Father Lisp won't bring them any parentheses when they hang out their
|bit buckets on Flag Day.
That's the right idea, but of course you are being flip here, the
manual certainly shouldn't be so cutesy as that.
∂09-Apr-85 0451 REM@IMSSS READ loses info as to whether package is specified or not, my fix
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-09 04:49:45 PST (=GMT-8hr)
Date: 1985 April 09 04:49:12 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132124132151.G0365
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To: "perdue%hplabs.csnet"@csnet-relay.arpa
CC: Common-LISP@SU-AI.ARPA
Subject: READ loses info as to whether package is specified or not, my fix
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM@MIT-MC.ARPA
|Date: 8-Apr-85 18:03:48
|Subject: Compilation and package system
|From: perdue%hplabs.csnet@csnet-relay.arpa
|It is surprising to me that there has not been discussion of
|the problems of compiling when there is a package system.
|The specific problem I have in mind is in the handling of
|symbols that are referred to in the input text without a package
|qualifier.
|
|The user of a Common LISP implementation sees the problem as a
|difference between the behavior of a module (file) loaded in its
|interpretive form and loaded in its compiled form. Specifically,
|references to symbols will in some cases be resolved differently
|depending on whether or not the file was compiled before being loaded.
I agree, this may indeed be a serious problem. I think the answer is
to flush the idea that any piece of LISPish text must run exactly the
same interpreted and compiled, and rather say that any correct LISP
program must run the same interpreted and compiled. We define a file
without an IN-PACKAGE at the beginning to NOT be a correct LISP
program. Thus it may still work interpreted, and compiled, although
differently, but the compiler should flag as an warning that it is not
a valid LISP program and might not execute as expected (as it did
interpreted).
∂09-Apr-85 0709 gls%AQUINAS.TMC@Think NIL and DEFCONSTANT [Gall: Bug Report]
Received: from [10.4.0.6] by SU-AI.ARPA with TCP; 9 Apr 85 07:08:58 PST
Received: by Think.ARPA with CHAOS id AA22257; Tue, 9 Apr 85 10:06:22 est
Date: Tue, 9 Apr 85 10:09 EST
From: Guy Steele <gls%AQUINAS.TMC@Think>
Subject: NIL and DEFCONSTANT [Gall: Bug Report]
To: common-lisp@SU-AI.ARPA
Cc: gls%AQUINAS.TMC@Think
In-Reply-To: <FAHLMAN.12101655193.BABYL@CMU-CS-C.ARPA>
Response to Fahlman:
Response to Steele:
Maybe a right attitude to take is that it is an error
to execute any compiled code that refers to a DEFCONSTANT'ed
name that has been re-DEFCONSTANT'ed to a different (non-EQL?)
value since the code was compiled.
Yeah, that seems reasonable. We want to be able to change the value of
a constant if, for example, we notice a typo, but once something has
been compiled that uses that constant, it is unpredictable which value
you get if you then change the constant.
That would say that it is okay to (DEFCONSTANT T 43), but then
you had better not execute any system code that refers to T.
But the evaluator probably refers to T, so in practice you had
simply better not do it.
This looks like trouble to me. I don't think we'd better tell the users
that this is legal but that they'd probably better not do it in
practice. Unlike us high-powered language designers, mere users are
likely to be confused by this. Maybe we'd just better tell them that it
is erroneous, wrongheaded, evil, and uncool to do this, and that if they
persist in this practice Father Lisp won't bring them any parentheses
when they hang out their bit buckets on Flag Day.
All I meant by this is that the evilness of redefining T follows logically
from (1) the proposed rule that allows users to carefully redefine things,
and (2) the fact that EVERYTHING depends on T. What we tell the user is
another story. An additional attitude is that it is reasonable for the
system to take a benevolent protective interest in those constants on which
it depends. (Translation: refuse to change T because everything will break.)
--Guy
∂09-Apr-85 1147 root%bostonu.csnet@csnet-relay.arpa Re: Arg count checking
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 9 Apr 85 11:47:22 PST
Received: from bostonu by csnet-relay.csnet id ab02727; 9 Apr 85 14:30 EST
Received: by bu-cs.ARPA (4.12/4.7)
id AA12160; Tue, 9 Apr 85 12:55:13 est
Date: Tue, 9 Apr 85 12:55:13 est
From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa>
To: card.pa@XEROX.ARPA, masinter.pa@XEROX.ARPA
Subject: Re: Arg count checking
Cc: bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA
> Date: 8 Apr 85 17:06 PST
> From: card.pa@XEROX.ARPA
> Subject: Re: Arg count checking
> ....
> DEFINEQ
> ((NSPRINT
> (LAMBDA (PRINTER
> (FILE.NAME OPTIONAL)
> (DOCUMENT.NAME OPTIONAL)
> (DOCUMENT.CREATION.DATE OPTIONAL)
> (RECIPIENT.NAME OPTIONAL)
> (#COPIES OPTIONAL)
> (MEDIUM OPTIONAL)
> (PRIORITY OPTIONAL)
> (STAPLE? OPTIONAL)
> (TWO.SIDED OPTIONAL)))))
>
> implements a function where the first argument PRINTER is mandatory and
> the remaining are all optional.
I agree but thought at this design stage I could throw my
two cents in. It seems that rather than those redundant OPTIONALs
a default value would be more useful, the fact that it is a list
rather than an atom is sufficient to deduce that this is a keyword
parameter (and it makes the whole thing consistent with PROG.)
That's it...just two cents worth.
-Barry Shein, Boston University
∂09-Apr-85 1341 DLW@SCRC-STONY-BROOK.ARPA Re: Arg count checking
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Apr 85 13:36:33 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211848; Tue 9-Apr-85 16:29:34-EST
Date: Tue, 9 Apr 85 16:31 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Re: Arg count checking
To: card.pa@XEROX.ARPA, masinter.pa@XEROX.ARPA
cc: bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 8 Apr 85 20:06-EST from card.pa@XEROX.ARPA
Message-ID: <850409163106.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
I don't think I understand the point of your message. What is the
difference between what you are proposing and Common Lisp keyword
arguments, other than syntax?
∂09-Apr-85 1352 DLW@SCRC-STONY-BROOK.ARPA Compilation and package system
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Apr 85 13:30:49 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211844; Tue 9-Apr-85 16:26:09-EST
Date: Tue, 9 Apr 85 16:27 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Compilation and package system
To: perdue%hplabs.csnet@CSNET-RELAY.ARPA, Common-lisp@SU-AI.ARPA
In-Reply-To: <8504090204.AA23590@HP-VENUS>
Message-ID: <850409162744.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
When the compiler compiles a file, it has to know what package to do the
READs in. If the compiler reads the symbols into the wrong package,
there's no hope. Our system has a convention that lets you tell the
compiler what package to use. The same convention tells the editor and
the loader what package to use as well.
∂09-Apr-85 1722 JLW Arg cont checking, optionals, keywords, etc
To: Card.pa@XEROX.ARPA
CC: bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA
Common Lisp has already developed a keyword argument syntax, so that
"optionals" may be passed in random order.
Until one actually gets down to implementing that proposal, he may be
frightened away by the thought that it would unduly slow down the
function calling protocol. I don't think it does (slow the vanilla
case down), but am not inclined to elucidate over network mail.
A major problem for Interlisp-D is, however, the backwards compatiblity
question. Whereas it may be quite all right to take a function, say,
(DEFINEQ (FOO (A B C) ...]
and redefine it like
(DEFINEQ (FOO (&OPTIONAL A B C) ...]
and, I think, even suffer no slowdown. But what if you really wanted
(DEFINEQ (FOO (A B &OPTIONAL C) ...]
Then a lot of code may have to be re-written (or perhaps massaged
mechanically) so that calls like (FOO 3) become (FOO 3 NIL). The
benefits of arg count checking won't be realized without breaking some
already running code.
-- JonL --
∂09-Apr-85 1803 Moon@SCRC-STONY-BROOK.ARPA Probe-File and proposed extension.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Apr 85 17:37:24 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211990; Tue 9-Apr-85 20:37:10-EST
Date: Tue, 9 Apr 85 20:37 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Probe-File and proposed extension.
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA, greek@DEC-HUDSON.ARPA
In-Reply-To: <RAM.12101610106.BABYL@CMU-CS-C.ARPA>
Message-ID: <850409203759.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 8 Apr 1985 18:29 EST
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
The point about relative pathnames is the following: When you
actually write a file, Open resolves any relative pathname down to an
absolute pathname. Any implementation that allows writing relative
pathnames must have some way to map the relative pathname to an
absolute pathname. This mapping is not necessarily the same as merge
pathnames, and in any case, there is no way in Common Lisp to
determine what the defaults are.
Well, the defaults for MERGE-PATHNAMES are whatever the program wants to
pass to merge-pathnames as an argument. I would hope that if OPEN has to
call MERGE-PATHNAMES, it would use *DEFAULT-PATHNAME-DEFAULTS*. But this
is moot since by relative pathnames you meant something different than I:
In Spice Lisp, when you open a file for write, Open first looks
for any file with that name on the default search list, and if found,
overwrites it, otherwise it creates a file in the current directory.
I will argue that this is the right semantics in our implementation,
and it is clearly implementation dependent.
Regardeless of the error issue, it would be useful to be able to
default a pathname for output in this fashion.
I see. This is not covered by the generic file-system model, but that
doesn't mean there is anything wrong with it. You need an interface to
this implementation-dependent feature, and the question is, should the
interface be defined in an implementation-independent way? Looked at
that way, the proposal for a :direction keyword to PROBE-FILE seems
pretty reasonable. Now that I understand it, this seems reasonable to
me, and perhaps it's time for you to make an explicit proposal.
On the other hand, you could always just add a function to Spice Lisp
that is just an implementation-dependent interface to Accent. Trying
to do file-system-related things in an implementation-independent way
can often be very tricky. I know of at least one file system that would
have some difficulty implementing this feature (specifically, getting the
version number right), although it probably wouldn't be impossible.
This should go on any lists that are being kept of proposed language
enhancements and clarifications.
As for the error issue, Spice Lisp currently does exactly what you
suggest. A user complained that this was not what the manual said it
should do. I tried both the Dec-20 Clisp and the Kyoto Common Lisp
implementations, and they both refused to signal errors, no matter
what garbage you gave them. I decided at this point that the issue
was unclear, but that the Spice Lisp implementation was probably
wrong.
I think the Spice Lisp implementation is right. I don't think any
implementation without an error-handling system can be used as a fair
test of the circumstances in which PROBE-FILE should signal an error.
∂09-Apr-85 1811 JLW Meaning of PROBE-FILE for direction output
To: moon@SCRC-STONY-BROOK.ARPA, ram@CMU-CS-C.ARPA,
greek@DEC-HUDSON.ARPA
CC: common-lisp@SU-AI.ARPA
There are a couple of problems with using a non-OPENing probe for
output files, which caused the Intelisp-D development group to want
to flush the equivalent [outfilep]. One problem is the obvious one that
when the result is non-null, it can be a guarantee only for a short
interval of time [I'm assuming that even personal workstations will be
having access to shared file servers] that such a file name may be
opened for writing by the caller -- because someone else may sneak in
and open up exactly the file you want. Another problem stems from a
possible discrepancy between the pathname completion done by the file
system when actually OPENing and when merely probing (without opening)
On the other hand, it appears as though some persons may feel as Paul
does, that using an "error" trap to do normal programming is bad practice.
A reasonable way out of this dilemma is simply to stop calling such signals
"errors", and admit signals as a first class mechanism. Xerox's Mesa language
has an admirable signalling mechanism, although a little too baroque for
my taste. The interface definition of any function then requires
a description of the types of input argments, the types of output values
(multple values) and an enumeration of any signals raised.
In pdp10 MacLisp days, all "signals" were raised via calling ERRORs; the
lossage with that approach is the too-limited bandwith of a single signal
(the ERROR signal).
So the "signal" approach would require the client program to actually do an OPEN
and to check for signals as well as the return value; there are numerous ways
to insure that an abort after the actual open will cause a close, but I
wonder what purpose would be served by providing a probe-file for output
operation if th client didn't actually open the file sooner or later anyhow.
-- JonL --
∂09-Apr-85 1915 WHOLEY@CMU-CS-C.ARPA Compilation and package system
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 Apr 85 19:15:26 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Tue 9 Apr 85 22:14:16-EST
Date: Tue, 9 Apr 1985 22:14 EST
Message-ID: <WHOLEY.12101913081.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: "Daniel L. Weinreb" <DLW%SCRC-Tenex@MIT-MC.ARPA>
CC: Common-lisp@SU-AI.ARPA, perdue%hplabs.csnet@CSNET-RELAY.ARPA
Subject: Compilation and package system
There are a number of ways to let the compiler know about the package that a
file will be loaded into. The portable, Common Lisp way to do this is with a
call to In-Package at the beginning of a file, as suggested in CLTL, on page
189. The Lisp Machine -*- file comment hack (which is used by the editor,
compiler, and loader) has a few drawbacks.
First of all, it is not portable. People write Common Lisp programs with a -*-
package specification, but these programs must be modified (by adding a real
In-Package to the program text) when they are moved to non-Lisp Machine Common
Lisps.
Secondly, one cannot put all of the information about the packages Use'd or
symbols Import'ed in the file comment. One cannot accurately fix up the
package environment by looking at the file comment. I suppose one could hair
it up to include imports and shadows and whatnot (maybe someone already has),
but that just leaves one with more stuff to "translate into Common Lisp" when
he moves his program off of the Lisp Machine.
Finally, the Symbolics Common Lisp Compatibility Package will give an error
when one attempts to load or compile a file with a header something like that
presented below, because it interprets the file comment, and wants to find any
package specified there before reading anything in the file. In fact, the
first form read may be the one that creates the package, so it may not be there
for the file comment gremlin to interpret. In-Package is a nice language
feature that Does The Right Thing, but has been rendered useless on the Lisp
Machine by zealous use of file comment magic.
We have adopted the convention that any -*- package specification is for the
editor only, and that the compiler and friends should get stuff out of Lisp
forms. Thus, a typical Spice Lisp system file might begin with something like:
;;; -*- Package: Lisp; Log: Code.Log -*-
;;;
;;; ...blah blah blah...
;;;
(in-package "LISP" :use '("SYSTEM"))
(export '(things that this file defines))
The editor knows which package to associate with a buffer created when visiting
this file, but the compiler and loader and everyone else just read Lisp forms,
the way Father Lisp wanted them to.
Since the -*- convention is not part of Common Lisp (and perhaps for good
reason), I would encourage EVERYONE writing Common Lisp programs to begin each
file in the way suggested in CLTL. Smart editors need to know things like the
package (so that functions compiled in the text editor end up in the right
package, for example), however, so it might be worth some effort to standardize
the semantics of -*- file comments. Unfortunately, I imagine neither the Lisp
Machine community nor the Spice Lisp community is willing to give in.
--Skef
∂09-Apr-85 1958 RICHER@SUMEX-AIM.ARPA Re: Arg cont checking, optionals, keywords, etc
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 9 Apr 85 19:57:50 PST
Date: Tue 9 Apr 85 19:57:32-PST
From: Mark Richer <RICHER@SUMEX-AIM.ARPA>
Subject: Re: Arg cont checking, optionals, keywords, etc
To: JLW@SU-AI.ARPA
cc: Card.pa@XEROX.ARPA, bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA,
RICHER@SUMEX-AIM.ARPA
In-Reply-To: Message from "Jon White <JLW@SU-AI.ARPA>" of Tue 9 Apr 85 17:22:00-PST
I wonder if Interlisp could have an option where arg checking was optional
or only done on functions with a certain editdate (beyond the date the
incompatibility is announced) without a penalty to users who set arg checking
to be done always?
mark
-------
∂10-Apr-85 1012 DDYER@USC-ISIB.ARPA
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 10:12:47 PST
FYI: Adding mandatory/optional argument checking to Interlisp-VAX
would be easy, and incur no additional overhead.
ReSent-Date: 10 Apr 1985 10:12:15 PST
ReSent-From: Dave Dyer <DDYER@USC-ISIB.ARPA>
ReSent-To: common-lisp@SU-AI.ARPA
Default values for &optional args would require a substantial
rethinking of the function call mechanism, as would &rest and
&key.
∂10-Apr-85 1024 DCP@SCRC-VALLECITO.ARPA What are we talking about anyway?
Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 10:24:09 PST
Received: from SCRC-NEPONSET by SCRC-VALLECITO via CHAOS with CHAOS-MAIL id 6908; Wed 10-Apr-85 13:22:59-EST
Date: Wed, 10 Apr 85 13:24 EST
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: What are we talking about anyway?
To: Dave Dyer <DDYER@USC-ISIB.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 10 Apr 85 13:12-EST from Dave Dyer <DDYER@USC-ISIB.ARPA>
Message-ID: <850410132431.9.NFEP@NEPONSET.SCRC.Symbolics.COM>
Date: 10 Apr 1985 10:12:15 PST
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
Received: from SCRC-STONY-BROOK by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 152301; Wed 10-Apr-85 13:15:37-EST
Received: from SU-AI.ARPA by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 212320; 10 Apr 85 13:13:52-EST
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 10:12:47 PST
FYI: Adding mandatory/optional argument checking to Interlisp-VAX
would be easy, and incur no additional overhead.
ReSent-Date: 10 Apr 1985 10:12:15 PST
ReSent-From: Dave Dyer <DDYER@USC-ISIB.ARPA>
ReSent-To: common-lisp@SU-AI.ARPA
Where did THAT header come from? There is no To: or From: fields.
Default values for &optional args would require a substantial
rethinking of the function call mechanism, as would &rest and
&key.
Point of information: Why are people discussing various implementations
of the Interlisp calling strategies on the common-lisp mailing list? As
I remember, this whole thing started because somebody didn't realize
what keyword arguments (in Common Lisp) are for.
∂10-Apr-85 1112 smh@mit-eddie.ARPA defstruct slot names
Received: from MIT-EDDIE.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 11:11:57 PST
Received: by mit-eddie.ARPA (4.12/4.8) id AA09669; Wed, 10 Apr 85 14:04:48 est
Date: Wed, 10 Apr 85 14:04:48 est
From: Steven M. Haflich <smh@mit-eddie.ARPA>
Message-Id: <8504101904.AA09669@mit-eddie.ARPA>
To: Common-Lisp@SU-AI.ARPA
Subject: defstruct slot names
I hope this wasn't discussed in the distant past.
The CLTL definition of the defstruct macro (p.308) has a hole which
deserves plugging. Each slot-name in the defstruct form is required
only to be a symbol. It would seem that the following is perfectly
legal, even if it has no clear motivation:
(defstruct automobile
engine:horsepower
insurance:dollar-value)
It is reasonable to assume that the constructor function can only
ignore the package of a slot-name regardless whether it is the same
package as the structure name. So this is OK:
(make-automobile :horsepower 289 :dollar-value 14500)
Anyway, this is probably what would happen in any obvious implementation
which had given this issue no thought at all. But consider:
(defstruct automobile
engine:horsepower
liability-insurance:dollar-value
collision-insurance:dollar-value)
While there is no requirement that slot-names be distinct, it is
reasonable that identical slot names should be an error. But the two
dollar-value slots are distinct even though they herniate the naming
scheme for constructor keywords and access-functions. The problem is
that slot names are semantically scoped within the structure containing
them, so packages are irrelevant. The ways in which slot names are used
rather assumes this, but the assumption is nowhere explicit.
Can anyone think of a legitimate use for packages in slots names? If
not, I propose the manual should explicitly state that defstruct interns
all slot names in the keyword package. Compare the definition of the
#S(name slot1 'value ...) reader syntax (p.357).
This issue will likely also affect active objects.
∂10-Apr-85 1156 FAHLMAN@CMU-CS-C.ARPA defstruct slot names
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 11:56:46 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 10 Apr 85 14:55:54-EST
Date: Wed, 10 Apr 1985 14:55 EST
Message-ID: <FAHLMAN.12102095449.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "Steven M. Haflich" <smh@MIT-EDDIE.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: defstruct slot names
In-reply-to: Msg of 10 Apr 1985 14:04-EST from Steven M. Haflich <smh at mit-eddie.ARPA>
I think that the motivation for allowing slot names to be non-keywords
was that it might be useful to have these be local to some particular
package. Of course, none of us was so perverse as to imagine that users
would (a) mix together a lot of packages in the same defstruct
definition and (b) then go on and introduce name conflicts among the
symbols. I think that instead of somehow trying to make this illegal,
we should just let the users hang themselves if they're that eager to do
so. If there was some way in which this situation might happen by
accident in halfway reasonable code, then it might be worthwhile to
check for this case and keep the user out of trouble, but I don't see
any potential for innocent lossage here.
-- Scott
"Nothing is foolproof because fools are so ingenious."
∂10-Apr-85 1159 RAM@CMU-CS-C.ARPA Meaning of PROBE-FILE for direction output
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 11:58:59 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 10 Apr 85 14:57:09-EST
Date: Wed, 10 Apr 1985 14:56 EST
Message-ID: <RAM.12102095659.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Jon White <JLW@SU-AI.ARPA>
Cc: common-lisp@SU-AI.ARPA, greek@DEC-HUDSON.ARPA, moon@SCRC-STONY-BROOK.ARPA
Subject: Meaning of PROBE-FILE for direction output
In-reply-to: Msg of 9 Apr 1985 21:11-EST from Jon White <JLW at SU-AI.ARPA>
I don't think that either of the problems of a non-opening probe
for output files that you mention are important.
The problem of the result only being valid for an arbitrarily
short period of is not unique to this function. When opening for
input, the file could be deleted or opened in a read-exclusive fashion
between the probe-file and any open attempt.
I'm not quite sure what sort of problem you are referring to in
the second case. Are you talking about the business of the version
number not being known, or what? The function I propose would
probably return a null version, since that could not be known.
Rob
∂10-Apr-85 1222 RAM@CMU-CS-C.ARPA Compilation and package system
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 12:22:39 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 10 Apr 85 15:16:32-EST
Date: Wed, 10 Apr 1985 15:16 EST
Message-ID: <RAM.12102099201.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: perdue%hplabs.csnet@CSNET-RELAY.ARPA
Cc: Common-lisp@SU-AI.ARPA
Subject: Compilation and package system
In-reply-to: Msg of 8 Apr 1985 18:03-EST from perdue%hplabs.csnet at csnet-relay.arpa
Yep, that's true. In the hurry to say that compiling code has no
effects on its semantics, the CLM glossed over some uglies that are
unlikely to go away.
One is the problem that you mention: reading throws away
information, so the load-time semantics cannot be the same with
compiled code. It would be nice if someone could decide what should
be guaranteed about the package semantics of symbols in compiled code.
Another problem involves the constraints placed on objects that
can be function constants.
1] Can any type of object be dumped? Compiled functions, hashtables,
streams? The answer is almost certainly no, but nowhere is it
specified what you can dump. A conservative rule would be to only
guarantee that readable objects can be dumped.
2] Is sharing and non-sharing preserved? Probably not.
3] Can circular structures can dumped? Note that they can be read
and printed.
Rob
∂10-Apr-85 1504 REM@IMSSS interp .neq. compil, even in CL
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-10 15:01:27 PST (=GMT-8hr)
Date: 1985 April 10 15:00:36 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132125241707.G0365
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:RAM@CMU-CS-C.ARPA
CC:COMMON-LISP@SU-AI.ARPA
Subject:interp .neq. compil, even in CL
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up)
|Date: Wed, 10 Apr 1985 15:16 EST
|From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
|
| Yep, that's true. In the hurry to say that compiling code has no
|effects on its semantics, the CLM glossed over some uglies that are
|unlikely to go away.
Hear! Hear!
You've brought up several items that ought to be explained in the
manual. It should say something like "Common LISP tries to make the
semantics of compiled programs and the semantics of their interpreted
sources as nearly identical as they can be. But certain processes such
as reading data in or writing it out lose information thereby causing
some differences between interpreted and compiled code: - READing an
s-expression containing unqualified identifiers (those with no
explicit package qualifier) to be assigned to a package at the time
they are read, thus causing compiled identifiers to be assigned to a
package which was default at the time of compiling rather than the
package that is default at the time the compiled code is later read
and executed. To force these two packages to be the same, the
IN-PACKAGE declaration is available (page ...). - When writing two
different s-expressions (using PRIN1 or via compiling and
FASL-writing), information about internal structure they share is
lost. There is no way short of hashcons to maintain that sharing over
a write-read cycle. ..." etc. etc.
This list of differences between interpreted and compiled software
should be summarized all in one place, as above, although details of
IN-PACKAGE and the like can be elsewhere. CLM should realize it has
not totally obtained the goal of interp/compil equivalence, and state
to which degree it has and hasn't succeeded, lest hundreds of LUSERs
discover for themselves (painfully) that we haven't told them the truth.
∂10-Apr-85 1933 Moon@SCRC-STONY-BROOK.ARPA Compilation and package system
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 19:33:06 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 212741; Wed 10-Apr-85 22:33:05-EST
Date: Wed, 10 Apr 85 22:33 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Compilation and package system
To: Skef Wholey <Wholey@CMU-CS-C.ARPA>
cc: Common-lisp@SU-AI.ARPA
In-Reply-To: <WHOLEY.12101913081.BABYL@CMU-CS-C.ARPA>
Message-ID: <850410223354.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 9 Apr 1985 22:14 EST
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
There are a number of ways to let the compiler know about the package that a
file will be loaded into. The portable, Common Lisp way to do this is with a
call to In-Package at the beginning of a file, as suggested in CLTL, on page
189. The Lisp Machine -*- file comment hack (which is used by the editor,
compiler, and loader) has a few drawbacks.
First of all, it is not portable. People write Common Lisp programs with a -*-
package specification, but these programs must be modified (by adding a real
In-Package to the program text) when they are moved to non-Lisp Machine Common
Lisps.
I guess it's a matter of viewpoint which way is non-portable, depending on which
way you're trying to port. But let's not get into that.
Secondly, one cannot put all of the information about the packages Use'd or
symbols Import'ed in the file comment. One cannot accurately fix up the
package environment by looking at the file comment. I suppose one could hair
it up to include imports and shadows and whatnot (maybe someone already has),
but that just leaves one with more stuff to "translate into Common Lisp" when
he moves his program off of the Lisp Machine.
We believe that complex package setups should go in their own files.
Finally, the Symbolics Common Lisp Compatibility Package will give an error
when one attempts to load or compile a file with a header something like that
presented below, because it interprets the file comment, and wants to find any
package specified there before reading anything in the file. In fact, the
first form read may be the one that creates the package, so it may not be there
for the file comment gremlin to interpret. In-Package is a nice language
feature that Does The Right Thing, but has been rendered useless on the Lisp
Machine by zealous use of file comment magic.
I don't think it would be constructive for me to respond to the above paragraph
in the same tone as it was written, so I will refrain.
We have adopted the convention that any -*- package specification is for the
editor only, and that the compiler and friends should get stuff out of Lisp
forms. Thus, a typical Spice Lisp system file might begin with something like:
;;; -*- Package: Lisp; Log: Code.Log -*-
;;;
;;; ...blah blah blah...
;;;
(in-package "LISP" :use '("SYSTEM"))
(export '(things that this file defines))
The editor knows which package to associate with a buffer created when visiting
this file, but the compiler and loader and everyone else just read Lisp forms,
the way Father Lisp wanted them to.
This all sounds at first like it makes a lot of sense, but wait a minute. I
fail to see how the editor needs any less information about packages than the
compiler and the loader. How does the editor know the names of the functions
in the file if it doesn't know what package they are relative to? How can the
editor understand forms in the file, telling you about arguments wanted by
functions, documentation of variables, syntax of macros, and so forth, if it
can't intern symbols whose printed representations it finds there? How can you
incrementally compile or load portions of the file being edited if the machine
doesn't know what package to read the forms in? Or does you editor make a
special pass through the file when it reads it in, looking for "(IN-PACKAGE "?
In our system all programs that read Lisp forms from files get the package
information from the same place and they all work consistently.
Since the -*- convention is not part of Common Lisp (and perhaps for good
reason), I would encourage EVERYONE writing Common Lisp programs to begin each
file in the way suggested in CLTL. Smart editors need to know things like the
package (so that functions compiled in the text editor end up in the right
package, for example), however, so it might be worth some effort to standardize
the semantics of -*- file comments. Unfortunately, I imagine neither the Lisp
Machine community nor the Spice Lisp community is willing to give in.
Probably not, considering that IN-PACKAGE was put into Common Lisp over my dead body.
This is my fault for not doing an adequate job of explaining why it was a bad idea
and only workable in the short run. As you say, it might be worth some effort to
standardize the semantics of -*-.
∂10-Apr-85 2006 GSB@MIT-MC Meaning of PROBE-FILE for direction output
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 20:05:46 PST
Date: Wed,10 Apr 85 23:04:40 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: Meaning of PROBE-FILE for direction output
To: common-lisp@SU-AI
Message-ID: <[MIT-MC].450268.850410.GSB>
Another timing problem with this is that any way of doing it which
involves actually doing the open might leave an entry in the
filesystem, even though only temporarily. I would not want to have to
simulate any hairy (tops-20, vms, especially version 4) operating
system's algorithm for determining if i had access -- ergo, i would
implement it by doing the open to see if it succeeds.
∂10-Apr-85 2051 WHOLEY@CMU-CS-C.ARPA Compilation and package system
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 20:51:22 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Wed 10 Apr 85 23:51:08-EST
Date: Wed, 10 Apr 1985 23:51 EST
Message-ID: <WHOLEY.12102192890.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: Common-lisp@SU-AI.ARPA
Subject: Compilation and package system
Date: Wednesday, 10 April 1985 22:33-EST
From: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Date: Tue, 9 Apr 1985 22:14 EST
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
First of all, it [the -*- comment convention] is not portable.
I guess it's a matter of viewpoint which way is non-portable, depending on
which way you're trying to port. But let's not get into that.
Let's get into that for just one paragraph. Nothing in CLTL says anything
about -*- comments. Files with those comments will have the effect that you
(Dave Moon) expect them to in only one Common Lisp implementation: the
Symbolics CLCP. The implementations done by DEC, DG, Rutgers, Kyoto
University, and CMU will not understand them. I realize that (by itself) this
kind of survey is a bad way to decide language design issues, but the reason
that those implementations do not hack -*- the Lisp Machine way is that there's
nothing in the spec that says they should.
We believe that complex package setups should go in their own files.
I have two programs that I've run on both Perqs and 3600's. One is a Common
Lisp version of OPS-5, and another is the Spice Lisp microcode assembler. Each
are contained in exactly one file, and are thus easy to move from system to
system. Why should I need to double the number of files in such systems?
For us, "complex package setups" are a way of life, because we've chosen to put
the code for communicating with each OS server in its own file. When I sit
down to write a graphics hack, I begin a file with
;;; -*- Package: Hack -*-
(in-package "HACK" :use '("LISP" "ACCINT" "SAPPH" "SESAME")).
I suppose our differences may stem from the fact that we Spice Lispers don't
think that packages are very expensive. Packages can be used for little hacks
as well as big systems. In the former case, one shouldn't need to stash this
information in a separate file that then must be loaded by hand (or in my init
file (or by some hook I frob in my init file)).
The editor knows which package to associate with a buffer created when
visiting this file, but the compiler and loader and everyone else just
read Lisp forms, the way Father Lisp wanted them to.
This all sounds at first like it makes a lot of sense, but wait a minute.
I fail to see how the editor needs any less information about packages than
the compiler and the loader. How does the editor know the names of the
functions in the file if it doesn't know what package they are relative to?
I guess I was being unclear. The editor interprets -*- comments, and
associates a package with the buffer the file was read into. This package is
made the default package (i.e. *package* is bound to it) whenever the editor
parses code in the file (e.g. for incremental compilation) or the echo area
(e.g. when asked to list the argument names of a given function).
If the package does not exist, then the user is asked if it should be created.
If that package uses packages other than LISP, then the user must evaluate the
In-Package or Use-Package or Import or whatever himself before counting on the
editor to parse code correctly. This last step could be automated, but we
haven't done it.
In our system all programs that read Lisp forms from files get the package
information from the same place and they all work consistently.
Ah, but all those programs have to do some magic thing (not part of the Common
Lisp language) to interpret the stuff between -*-'s in the first line of the
file. Should a user be able to write a portable slow-loader (that just reads
forms from a given file) or not? I think he should. People should be able to
write things like program cross-referencers in Common Lisp. Portable Common
Lisp (whatever that means).
IN-PACKAGE was put into Common Lisp over my dead body.
The rumors of your death have been greatly exaggerated.
It might be worth some effort to standardize the semantics of -*-.
How about this: Symbolics could provide a portable -*- comment hacking package.
This would be made part of the yellow pages, and all implementations could
"voluntarily" adopt it as a thing that gets called by Load, Compile-File, etc.
This might then be adopted in Common Lisp Mark II (it's really no worse than
FORMAT, I guess). I'm still personally biased against this idea (I really do
believe that a slow-loader should just read forms out of a file), but portable
code would make the Lisp Machine convention a lot easier to swallow.
On the other hand, we could decide that -*-'s don't port, and warn users about
differences from system to system. Rob MacLachlan has suggested a very
sinister solution to the problem: conditionalized constructs in -*- coments...
-*- #+LISPM{Syntax: Common-Lisp; Uppercase: Mostly;} Package: Zippy -*-
--Skef
∂10-Apr-85 2137 KMP@SCRC-STONY-BROOK.ARPA Compilation and package system
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 21:37:00 PST
Received: from SCRC-RIO-DE-JANEIRO by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 212797; Thu 11-Apr-85 00:37:00-EST
Date: Thu, 11 Apr 85 00:35 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Compilation and package system
To: Wholey@CMU-CS-C.ARPA, Moon@SCRC-STONY-BROOK.ARPA
cc: Common-lisp@SU-AI.ARPA
In-Reply-To: <WHOLEY.12102192890.BABYL@CMU-CS-C.ARPA>
Message-ID: <850411003554.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Wed, 10 Apr 1985 23:51 EST
Message-ID: <WHOLEY.12102192890.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: Common-lisp@SU-AI.ARPA
Subject: Compilation and package system
Date: Wednesday, 10 April 1985 22:33-EST
From: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Date: Tue, 9 Apr 1985 22:14 EST
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
First of all, it [the -*- comment convention] is not portable.
I guess it's a matter of viewpoint which way is non-portable, depending on
which way you're trying to port. But let's not get into that.
Let's get into that for just one paragraph. Nothing in CLTL says anything
about -*- comments. Files with those comments will have the effect that you
(Dave Moon) expect them to in only one Common Lisp implementation: the
Symbolics CLCP. The implementations done by DEC, DG, Rutgers, Kyoto
University, and CMU will not understand them. I realize that (by itself) this
kind of survey is a bad way to decide language design issues, but the reason
that those implementations do not hack -*- the Lisp Machine way is that there's
nothing in the spec that says they should.
Don't be silly. Common Lisp programs don't have to run gracefully in all
implementations, they just have to run. If a person has written -*- ... -*-
and not put (IN-PACKAGE ...), he has not written a common lisp program.
But that doesn't mean the Lisp Machine doesn't support IN-PACKAGE. If a
person has put (IN-PACKAGE ...) but no -*- ... -*- that means his program
will run in the way Common Lisp says it will, but that doesn't mean it will
interface gracefully to parts of the system not specified by Common Lisp.
The Lisp Machine simply (and reasonably) suggests that in order to work
compatibly with non-Common-Lisp utilities and still be portable, you should
do -*- ... -*- and (IN-PACKAGE ...), redundantly. In fact, I suspect that
users will be content to use simply -*- ... -*- and add (IN-PACKAGE ...) only
when they get around to actually shipping files but that shouldn't matter.
We believe that complex package setups should go in their own files.
I have two programs that I've run on both Perqs and 3600's. One is a Common
Lisp version of OPS-5, and another is the Spice Lisp microcode assembler. Each
are contained in exactly one file, and are thus easy to move from system to
system. Why should I need to double the number of files in such systems?
For us, "complex package setups" are a way of life, because we've chosen to put
the code for communicating with each OS server in its own file. When I sit
down to write a graphics hack, I begin a file with
;;; -*- Package: Hack -*-
(in-package "HACK" :use '("LISP" "ACCINT" "SAPPH" "SESAME")).
I suppose our differences may stem from the fact that we Spice Lispers don't
think that packages are very expensive. Packages can be used for little hacks
as well as big systems. In the former case, one shouldn't need to stash this
information in a separate file that then must be loaded by hand (or in my init
file (or by some hook I frob in my init file)).
Of course, for this sort of thing I usually just write:there's the alternate syntax:
;;; -*- Package: ("HACK" :USE ("LISP" "ACCINT" "SAPPH" "SESAME")) -*-
which seems to work OK...
The editor knows which package to associate with a buffer created when
visiting this file, but the compiler and loader and everyone else just
read Lisp forms, the way Father Lisp wanted them to.
This all sounds at first like it makes a lot of sense, but wait a minute.
I fail to see how the editor needs any less information about packages than
the compiler and the loader. How does the editor know the names of the
functions in the file if it doesn't know what package they are relative to?
I guess I was being unclear. The editor interprets -*- comments, and
associates a package with the buffer the file was read into. This package is
made the default package (i.e. *package* is bound to it) whenever the editor
parses code in the file (e.g. for incremental compilation) or the echo area
(e.g. when asked to list the argument names of a given function).
If the package does not exist, then the user is asked if it should be created.
If that package uses packages other than LISP, then the user must evaluate the
In-Package or Use-Package or Import or whatever himself before counting on the
editor to parse code correctly. This last step could be automated, but we
haven't done it.
In our system all programs that read Lisp forms from files get the package
information from the same place and they all work consistently.
Ah, but all those programs have to do some magic thing (not part of the Common
Lisp language) to interpret the stuff between -*-'s in the first line of the
file. Should a user be able to write a portable slow-loader (that just reads
forms from a given file) or not? I think he should. People should be able to
write things like program cross-referencers in Common Lisp. Portable Common
Lisp (whatever that means).
Don't forget the Lisp Machine uses -*- ... -*- for other languages besides lisp.
(IN-PACKAGE ...) would not work at the top of files in other languages besides
lisp and we don't have hands in design groups for every existing language so
cannot always get those languages to add a syntax for specifying the package.
Putting it in a comment is mostly likely to win in all languages since nearly
every language has a comment syntax and I know of no languages for which the
comment syntax is not compatible with -*- ... -*-.
IN-PACKAGE was put into Common Lisp over my dead body.
The rumors of your death have been greatly exaggerated.
It might be worth some effort to standardize the semantics of -*-.
How about this: Symbolics could provide a portable -*- comment hacking package.
This would be made part of the yellow pages, and all implementations could
"voluntarily" adopt it as a thing that gets called by Load, Compile-File, etc.
This might then be adopted in Common Lisp Mark II (it's really no worse than
FORMAT, I guess). I'm still personally biased against this idea (I really do
believe that a slow-loader should just read forms out of a file), but portable
code would make the Lisp Machine convention a lot easier to swallow.
On the other hand, we could decide that -*-'s don't port, and warn users about
differences from system to system. Rob MacLachlan has suggested a very
sinister solution to the problem: conditionalized constructs in -*- coments...
-*- #+LISPM{Syntax: Common-Lisp; Uppercase: Mostly;} Package: Zippy -*-
--Skef
∂11-Apr-85 0044 WHOLEY@CMU-CS-C.ARPA Compilation and package system
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 00:41:22 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Thu 11 Apr 85 03:41:09-EST
Date: Thu, 11 Apr 1985 03:41 EST
Message-ID: <WHOLEY.12102234761.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: Common-lisp@SU-AI.ARPA, Moon@SCRC-STONY-BROOK.ARPA
Subject: Compilation and package system
In-reply-to: Msg of 11 Apr 1985 00:35-EST from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Date: Thursday, 11 April 1985 00:35-EST
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Don't be silly. Common Lisp programs don't have to run gracefully in all
implementations, they just have to run. If a person has written -*- ... -*-
and not put (IN-PACKAGE ...), he has not written a common lisp program.
Right. That was what I said in the last paragraph in my original message on
this topic.
The Lisp Machine simply (and reasonably) suggests that in order to work
compatibly with non-Common-Lisp utilities and still be portable, you should
do -*- ... -*- and (IN-PACKAGE ...), redundantly.
Right. That's the way Spice Lisp works, too, more or less, as I've explained.
The difference in the two implementations comes up in only one case, but a very
common one. If, in CLCP, I load or compile a file with a -*- comment that puts
it in package FOO, and package FOO does not exist, then I get an error. Every
time this has happened to me, it has been the case that the first form of FOO
would have created the package.
Of course, for this sort of thing I usually just write:there's the
alternate syntax:
;;; -*- Package: ("HACK" :USE ("LISP" "ACCINT" "SAPPH" "SESAME")) -*-
which seems to work OK...
What about IMPORT and friends? Those matter, too.
Putting it in a comment is mostly likely to win in all languages since
nearly every language has a comment syntax and I know of no languages for
which the comment syntax is not compatible with -*- ... -*-.
The example I gave above, with the FOO package, leads to a situation where the
Lisp Machine signals an error when handed a valid program. That would suggest
that Common Lisp is a language which is not compatible with -*- comments, as
interpreted the Lisp Machine way.
If you think this is nitpicking, fine: we'll drop it. I doubt many man-years
will be lost fixing headers while porting between Common Lisp dialects. The
problem has annoyed at least one Common Lisp programmer, however.
--Skef
∂11-Apr-85 0607 greek@DEC-HUDSON PROBE-FILE
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 06:07:30 PST
Date: Thu, 11 Apr 85 09:07:38 EST
From: greek@DEC-HUDSON
Subject: PROBE-FILE
To: common-lisp@su-ai
At the risk of continuing a well-beaten subject:
I agree with Kent that there is no pleasant way of returning all the
possible errors from PROBE-FILE, and that some kind of objecty signalling
facility is probably the right way to go.
However, I just really have a problem with handling "normal" errors
using an error system. I can barely keep from gagging when I have to
wrap an UNWIND-PROTECT around something every six months or so.
To have to wrap various signal-handling forms all over the place...
- Paul
∂11-Apr-85 0649 greek@DEC-HUDSON A comment on packages (at the risk of being a fool)
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 06:49:00 PST
Date: Thu, 11 Apr 85 09:11:31 EST
From: greek@DEC-HUDSON
Subject: A comment on packages (at the risk of being a fool)
To: common-lisp@su-ai
We've had lots of discussion on the differences being interpreting
and compiling when using symbols without package prefixes.
I believe the rule with the slow loader is that an unqualified
symbol is loaded into the current package, which may or may not
have been established with an IN-PACKAGE at the top of the file.
Why doesn't the compiler simply do the same thing?
Namely, it sets the current package to "SPECIAL-COMPILER-PACKAGE-NO-ONE-
ELSE-CAN-USE". Then it read/compiles the file and arranges that any
symbols in that special package will be fast loaded into what is then
the current package. If the user has an IN-PACKAGE at the top of the
file, then no symbols will end up in that special package -- fine.
Am I missing something?
- Paul
∂11-Apr-85 1052 Moon@SCRC-QUABBIN.ARPA A comment on packages (at the risk of being a fool)
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 10:52:26 PST
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 152716; Thu 11-Apr-85 13:38:26-EST
Date: Thu, 11 Apr 85 13:38 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: A comment on packages (at the risk of being a fool)
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 11 Apr 85 09:11-EST from greek at DEC-HUDSON
Message-ID: <850411133853.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 11 Apr 85 09:11:31 EST
From: greek@DEC-HUDSON
We've had lots of discussion on the differences being interpreting
and compiling when using symbols without package prefixes.
I believe the rule with the slow loader is that an unqualified
symbol is loaded into the current package, which may or may not
have been established with an IN-PACKAGE at the top of the file.
Why doesn't the compiler simply do the same thing?
Namely, it sets the current package to "SPECIAL-COMPILER-PACKAGE-NO-ONE-
ELSE-CAN-USE". Then it read/compiles the file and arranges that any
symbols in that special package will be fast loaded into what is then
the current package. If the user has an IN-PACKAGE at the top of the
file, then no symbols will end up in that special package -- fine.
Am I missing something?
Think about executing, at compile time, the bodies of macros defined in the file.
∂11-Apr-85 1103 OLDMAN@USC-ISI.ARPA Data General Common LISP
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 11:02:13 PST
Date: 11 Apr 1985 14:01-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: Data General Common LISP
From: OLDMAN@USC-ISI.ARPA
To: Common-Lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]11-Apr-85 14:01:51.OLDMAN>
DG has recently released Common LISP running on its 32 bit family
of machines. A brief summary of the implementation and a list of
benchmark timings is available on USC-ISI in:
ps:<oldman>dg-common-lisp
-- Dan Oldman
∂11-Apr-85 1128 KMP@SCRC-YUKON.ARPA PROBE-FILE
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 11:28:00 PST
Received: from SCRC-RIO-DE-JANEIRO by SCRC-YUKON via CHAOS with CHAOS-MAIL id 118912; Thu 11-Apr-85 14:28:52-EST
Date: Thu, 11 Apr 85 14:26 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: PROBE-FILE
To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 11 Apr 85 09:07-EST from greek at DEC-HUDSON
Message-ID: <850411142639.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Thu, 11 Apr 85 09:07:38 EST
From: greek@DEC-HUDSON
... I agree with Kent that there is no pleasant way of returning all the
possible errors from PROBE-FILE, and that some kind of objecty signalling
facility is probably the right way to go.
However, I just really have a problem with handling "normal" errors
using an error system. I can barely keep from gagging when I have to
wrap an UNWIND-PROTECT around something every six months or so.
To have to wrap various signal-handling forms all over the place...
Well, in fact one of the "nice" things about this is that because you know
you'll get thrown into the error handler if something funny happens, you
can sometimes write your code without the error handling and add it lazily
if it's ever needed.
In dialects where PROBEF can fail due to other than file-not-found, you may
have the problem that the program will "finish" but not correctly. At least
if an error is not signalled, you know things worked correctly. For many
applications, this means writing
(COND ((NOT (PROBEF ...)) ;File is not found
...)
(T ;File is found
...))
where formerly (with a PROBEF that refuses to err) you might really have
been forced into doing something like:
(COND ((NOT (PROBEF ...)) ;Hmmm... File is either not found
;or not available or not correctly named or ...
(COND (...hair to figure out what to do if name was bad...)
(...hair to figure out what to do if not accessible...
machine down? drive offline? file write opened in
append mode by someone else and therefore locked?
no more of some needed system resource? ...)
(T ...the only part i really cared about...)))
(T ;File is found
...))
in order to be able to get to sleep at night with a clean conscience.
I guess what I'm saying is that in Maclisp, I've always considered programmers
irresponsible if they wrote "simplified" code that didn't handle the hairy
cases because they were just setting up to cause lossage when someone ran
their program in unusual circumstances.
On the other, Lisp Machine Lisp programmers that don't write code to handle
the hairy cases are often being sensible. They can have some sense of confidence
that if an unusual situation arises, the program will stop dead in its tracks
instead of producing bad data.
Given the choice between a buggy program that enters the error handler
and a buggy program which just continues to run blindly, I nearly always
prefer the former.
So, perhaps surprisingly, I'm suggesting that using error signalling may
simplify (rather than complicate) the look of code and maybe people with
hairy-construct phobias will actually like this...
-kmp
∂11-Apr-85 1156 FAHLMAN@CMU-CS-C.ARPA PROBE-FILE
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 11:56:14 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 11 Apr 85 14:56:03-EST
Date: Thu, 11 Apr 1985 14:55 EST
Message-ID: <FAHLMAN.12102357619.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: PROBE-FILE
In-reply-to: Msg of 11 Apr 1985 14:26-EST from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
I've avoided stepping into this particular discussion (and probably will
regret doing so now) but it looks to me like it might be time to try to
close the issue, for now at least. Let me toss out the following
suggestions to see if they are acceptable to everyone:
1. It is allowable for a Common Lisp system to signal an error on probef
if the file name is malformed in some way, or if the file is not found
for other than the usual reasons.
2. Implementations that don't want to handle this with an error, perhaps
because they lack an error-handling system of sufficient power, can for
now do something compatible but non-portable about this, such as taking
a special keyword or returning an extra value describing what went
wrong.
3. We should try again for a clean, fully portable solution to this
problem after we have reached some consensus on a standard
signal/error-handling system. At that point, we'll be able to see much
more clearly whether this is a good way to deal with this sort of
situation.
-- Scott
∂11-Apr-85 1227 greek@DEC-HUDSON PROBE-FILE
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 12:27:39 PST
Date: Thu, 11 Apr 85 15:27:49 EST
From: greek@DEC-HUDSON
Subject: PROBE-FILE
To: common-lisp@su-ai
Scott's suggestion seems reasonable to me. We should avoid getting
bogged down in specific error-handling problems until we think about
a general signaling mechanism.
- Paul
∂11-Apr-85 1237 greek@DEC-HUDSON PROBE-FILE
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 12:37:08 PST
Date: Thu, 11 Apr 85 15:37:13 EST
From: greek@DEC-HUDSON
Subject: PROBE-FILE
To: common-lisp@su-ai
That's not to say that I like handling errors with a signaling facility,
but I guess I'm willing to change...
- Paul
∂11-Apr-85 1237 greek@DEC-HUDSON The compiler and packages.
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 12:35:10 PST
Date: Thu, 11 Apr 85 15:35:16 EST
From: greek@DEC-HUDSON
Subject: The compiler and packages.
To: common-lisp@su-ai
Well, Mr. Moon, I gave your comment some thought. It was a bit terse,
but perhaps this is what you meant:
What happens if a macro calls a function during the expansion of a
macro call? If that function is in, say, the "USER" package, and the
compiler were to make the current package "SPECIAL-COMPILER-PACKAGE-
THAT-NO-ONE-ELSE-USES", then indeed the function wouldn't be found
at compile time.
But then again, it wouldn't be found if the user didn't happen to be
in the "USER" package when compiling the program. If the program
must be compiled in the "USER" package, it ought to do an IN-PACKAGE
at the top.
If I read you wrong, please let me know.
By the way, here's what VAX LISP currently does: If the compiler goes
to dump a symbol which is in the current package (not any special
compiler package), then it dumps it without a package. This means
it will be loaded into the current package at the time of loading.
I don't think this is quite right, since it means that if I'm in
the "FOO" package when I compile, and I say FOO::SYM, and then I'm
in "BAR" when I load it, SYM will end up in "BAR" rather than "FOO".
To avoid this problem, I think you need the special compiler package.
- Paul
∂11-Apr-85 1302 dzg@cmu-cs-spice.arpa Probe-file and errors
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 13:01:41 PST
Apparently-From: dzg@CMU-CS-SPICE
Date: Thu 11 Apr 85 15:41:18-EST
From: dzg@CMU-CS-SPICE.ARPA
To: common-lisp@SU-AI.ARPA
Subject: Probe-file and errors
Message-ID: <6595.160879383.>
What seems to be impossible, for some reason, is to make simple things simple.
Here is the original application I had in mind:
- I need to find a dictionary file that is the key to everything else.
Access is to a remote machine of unspecified nature.
- Depending on the remote file system, the dictionary file may be under
different paths (e.g. /usr/xxx for a Unix machine, and so on).
- There are only two or three possible remote paths, one per machine, maybe.
- My code just wants to do
(cond ((probe-file "/usr/foo/bar")
...)
((probe-file "/user/may/be")
...)
((probe-file "/yet/another/one")
...)
(t
... cannot find it. Bye. ...))
Simple as that.
I do not (DO NOT!) want to handle an error. This is the simplest possible
thing I can ask of a file system. Do you have it or not? I couldn't care
less that the pathname is malformed because Unix directories must sit under
/usr/. I just want to see whether the file is there.
I understand there may be serious cases when one wants to "stop dead in the
tracks". I am willing to believe one really cares to find out why the file
system thinks there is no such file because the color of the third bit in
the filename is not blue. But I do want to have a simple call. I have seen
many systems that use exception handling as a way of passing arguments,
and they are NOT the clearest systems I have seen.
- Dario -
∂11-Apr-85 1613 Moon@SCRC-STONY-BROOK.ARPA PROBE-FILE
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 16:11:36 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 213650; Thu 11-Apr-85 19:07:53-EST
Date: Thu, 11 Apr 85 19:09 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: PROBE-FILE
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12102357619.BABYL@CMU-CS-C.ARPA>
Message-ID: <850411190901.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 11 Apr 1985 14:55 EST
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
....Let me toss out the following
suggestions to see if they are acceptable to everyone....
Fine with me.
∂11-Apr-85 1702 Moon@SCRC-STONY-BROOK.ARPA The compiler and packages.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 17:02:21 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 213672; Thu 11-Apr-85 20:01:29-EST
Date: Thu, 11 Apr 85 20:02 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: The compiler and packages.
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 11 Apr 85 15:35-EST from greek at DEC-HUDSON
Message-ID: <850411200255.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 11 Apr 85 15:35:16 EST
From: greek@DEC-HUDSON
Well, Mr. Moon, I gave your comment some thought. It was a bit terse,
but perhaps this is what you meant:
What happens if a macro calls a function during the expansion of a
macro call? If that function is in, say, the "USER" package, and the
compiler were to make the current package "SPECIAL-COMPILER-PACKAGE-
THAT-NO-ONE-ELSE-USES", then indeed the function wouldn't be found
at compile time.
What if the function was in the LISP package? Does your special compiler
package inherit from there or doesn't it? If it doesn't, macros can't
run. If it does, you can't tell whether a symbol came from there via
package prefix or via inheritance.
But then again, it wouldn't be found if the user didn't happen to be
in the "USER" package when compiling the program. If the program
must be compiled in the "USER" package, it ought to do an IN-PACKAGE
at the top.
If I read you wrong, please let me know.
By the way, here's what VAX LISP currently does: If the compiler goes
to dump a symbol which is in the current package (not any special
compiler package), then it dumps it without a package. This means
it will be loaded into the current package at the time of loading.
In other words, it does the same thing as PRINT. This is what our compiler
does, too.
I don't think this is quite right, since it means that if I'm in
the "FOO" package when I compile, and I say FOO::SYM, and then I'm
in "BAR" when I load it, SYM will end up in "BAR" rather than "FOO".
To avoid this problem, I think you need the special compiler package.
A better approach is for the compiler to tell the loader what the value
of *PACKAGE* was when the file was compiled. If the loader binds
*PACKAGE* to the same value (that is, to a package with the same name)
when the file is loaded, symbol names in the compiled file will be
interpreted as the compiler intended when it dumped them. This approach
works well for us. Of course the user can get into arbitrary amounts of
trouble by changing package definitions between the time a file is compiled
and the time it is loaded, but that is inherently unavoidable. For instance,
if the source file referenced FOO::SYM, and SYM was imported or inherited
by the source file's package at compile time, but not at load time, then
the wrong SYM will be referenced.
∂11-Apr-85 1852 masinter.pa@Xerox.ARPA Common Lisp should use lexical scoping
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 18:46:35 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 APR 85 18:42:42 PST
Date: 11 Apr 85 18:42 PST
From: masinter.pa@Xerox.ARPA
Subject: Common Lisp should use lexical scoping
To: Common-Lisp@SU-AI.ARPA
I think Common Lisp should use lexical scoping and not dynamic scoping.
Dynamic scoping is the cause of some subtle incompatibilities between
compiled and interpreted code.
Of course, I'm not talking about the scoping of variables, but rather of
packages. The "package" of a piece of code is really a lexical property
of the code. The fact that packages are dynamic in extent rather than
lexical has led to almost all of the problems in defining what happens
to packages and the compiler.
I believe that lexical scoping for packages would require some extra
syntax. I'm not sure I'm up for proposing what that syntax should be,
but I'd guess that some kind of reader macro(s) would be appropriate
replacements for the Extremely Random User Interface Commands. (Imagine
"#;;;-*- Package:" as a reader macro.)
It would then be reasonable to expect the compiler to preserve the
lexical scoping of packages, but the mechanism can now be part of the
implementation.
It would remove the odd restrictions on the compiler mechanisms (as
suggested by the implementation note in CLTL p 182) and much of the
necessity for having some of the more arcane features of the Packages
chapter.
∂11-Apr-85 1932 masinter.pa@Xerox.ARPA probe-file
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 19:27:46 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 APR 85 19:27:54 PST
Date: 11 Apr 85 19:27 PST
From: masinter.pa@Xerox.ARPA
Subject: probe-file
To: common-lisp@su-ai.ARPA
Probe-file is useful but necessarily heuristic, even for output mode.
(The Interlisp equivalent is called OUTFILEP, and hasn't been flushed.)
Let us suppose a that we had probe-file-that-generates-errors. This is
the one that does the probe-file, but generates errors if the file name
has illegal syntax, the server is down, etc. Lets suppose for a moment
that the error string in the error is always (kind of error: additional
information), e.g. "file server not responding: name-of-server".
Let me define a new function probe-file-without-errors, defined to
return the value of probe-file-that-generates-errors if the latter
returns non-NIL without errors, or else NIL and an optional second
argument, which is the "error code". Lets say that the error code is a
list of strings.
Note that there is some mutual property of these two functions, in that
either is relatively simple to implement in terms of the other, given an
error system of the imagined complexity of the Common Lisp error system.
Which would you prefer to have in the "standard" Common Lisp? Both?
Which would fit well with "most programs"? Which would "most
programmers" naturally chose if they had both available in their
library?
Given that probe-file is, on any machine except stand-alone
single-process systems, a heuristic at best, I'd claim that
probe-file-without-errors is more useful. I would claim that "can't
tell" is also a reasonable "error" code, and that it would be legitimate
(but not particularly useful) for an implementation to always return NIL
to probe-file, with "can't tell" as the reason.
∂11-Apr-85 1937 FAHLMAN@CMU-CS-C.ARPA Common Lisp should use lexical scoping
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 19:37:40 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 11 Apr 85 22:37:47-EST
Date: Thu, 11 Apr 1985 22:37 EST
Message-ID: <FAHLMAN.12102441681.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: masinter.pa@XEROX.ARPA
Cc: Common-Lisp@SU-AI.ARPA
Subject: Common Lisp should use lexical scoping
In-reply-to: Msg of 11 Apr 1985 21:42-EST from masinter.pa at Xerox.ARPA
Interesting suggestion if packages are used only for loading chunks of
already-developed code, but it's not clear to me that lexically scoped
packages would work out for interactive program development, where you
sometimes need to bop back and forth from one package environment to
another, adding code incrementally.
-- Scott
∂11-Apr-85 2127 masinter.pa@Xerox.ARPA Re: PROBE-FILE
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 21:27:22 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 APR 85 21:24:34 PST
Date: 11 Apr 85 21:24 PST
From: masinter.pa@Xerox.ARPA
Subject: Re: PROBE-FILE
In-reply-to: various messages
To: common-lisp@SU-AI.ARPA
I missed some of the mail on probe-file before firing off my suggestion.
I think deferring discussion until after resolution of some of the error
system questions sounds reasonable.
∂11-Apr-85 2139 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: PROBE-FILE
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 21:39:17 PST
Posted-Date: 12 Apr 85 00:23 EST
Date: Fri, 12 Apr 85 00:21 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: Re: PROBE-FILE
To: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 11 Apr 85 14:55 EST from "Scott E. Fahlman"
Message-ID: <850412052150.000502@MIT-MULTICS.ARPA>
Date: 11 April 1985 14:55 est
From: Scott E. Fahlman <Fahlman at CMU-CS-C>
Subject: PROBE-FILE
I've avoided stepping into this particular discussion (and probably will
regret doing so now) but it looks to me like it might be time to try to
close the issue, for now at least. Let me toss out the following
suggestions to see if they are acceptable to everyone:
1. It is allowable for a Common Lisp system to signal an error on probef
if the file name is malformed in some way, or if the file is not found
for other than the usual reasons.
2. Implementations that don't want to handle this with an error, perhaps
because they lack an error-handling system of sufficient power, can for
now do something compatible but non-portable about this, such as taking
a special keyword or returning an extra value describing what went
wrong.
3. We should try again for a clean, fully portable solution to this
problem after we have reached some consensus on a standard
signal/error-handling system. At that point, we'll be able to see much
more clearly whether this is a good way to deal with this sort of
situation.
-- Scott
I think the signalling of an error in the case of a namestring that is
syntactically illegal is an entirely separate issue that applies to most
of the file system interface function.
Many functions besides PROBE-FILE can take a namestring as an argument
(e.g., PATHNAME, OPEN, RENAME-FILE,DELETE-FILE). Nowhere does the CLRM
define what occurs if one of these functions is given a syntactically
illegal namestring.
Only PARSE-NAMESTRING is explicitly defined to signal an error "if the
[name]string does not consist entirely of the representation of a
pathname."
My suggestions are as follows:
1. The function PATHNAME be defined to signal an error if given a
syntactically illegal namestring.
2. The parameter names FILE, FILENAME, and THING be flushed and
replaced with PATHNAME.
3. Explicity state that all functions that take a PATHNAME argument
implicity apply the function PATHNAME to the argument.
This would mean that PROBE-FILE WOULD signal an error if given a
syntactically illegal namestring. Otherwise, if PROBE-FILE is given a
legal namestring, it should NOT signal an error if the pathname is
SEMANTICALLY illegal (e.g., non-existent dir.), I assumed this is what
TRUENAME was for. (If this is not the case, what IS the dif. between
PROBE-FILE and TRUENAME).
∂12-Apr-85 0701 greek@DEC-HUDSON A-Packaging we will go...
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 12 Apr 85 07:00:12 PST
Date: Fri, 12 Apr 85 10:00:19 EST
From: greek@DEC-HUDSON
Subject: A-Packaging we will go...
To: common-lisp@su-ai
[My new comments are in square brackets -- Paul.]
Well, Mr. Moon, I gave your comment some thought. It was a bit terse,
but perhaps this is what you meant:
What happens if a macro calls a function during the expansion of a
macro call? If that function is in, say, the "USER" package, and the
compiler were to make the current package "SPECIAL-COMPILER-PACKAGE-
THAT-NO-ONE-ELSE-USES", then indeed the function wouldn't be found
at compile time.
What if the function was in the LISP package? Does your special compiler
package inherit from there or doesn't it? If it doesn't, macros can't
run. If it does, you can't tell whether a symbol came from there via
package prefix or via inheritance.
[Well, as you say, it must inherit from the LISP package.
But why do I care whether the compiler can tell that the symbol had
a package prefix or inherited the symbol? The fact is that the symbol
is in the LISP package, so the fast loader better find it there.]
But then again, it wouldn't be found if the user didn't happen to be
in the "USER" package when compiling the program. If the program
must be compiled in the "USER" package, it ought to do an IN-PACKAGE
at the top.
If I read you wrong, please let me know.
By the way, here's what VAX LISP currently does: If the compiler goes
to dump a symbol which is in the current package (not any special
compiler package), then it dumps it without a package. This means
it will be loaded into the current package at the time of loading.
In other words, it does the same thing as PRINT. This is what our compiler
does, too.
[But do we agree that's correct?]
I don't think this is quite right, since it means that if I'm in
the "FOO" package when I compile, and I say FOO::SYM, and then I'm
in "BAR" when I load it, SYM will end up in "BAR" rather than "FOO".
To avoid this problem, I think you need the special compiler package.
A better approach is for the compiler to tell the loader what the value
of *PACKAGE* was when the file was compiled. If the loader binds
*PACKAGE* to the same value (that is, to a package with the same name)
when the file is loaded, symbol names in the compiled file will be
interpreted as the compiler intended when it dumped them. This approach
works well for us. Of course the user can get into arbitrary amounts of
trouble by changing package definitions between the time a file is compiled
and the time it is loaded, but that is inherently unavoidable. For instance,
if the source file referenced FOO::SYM, and SYM was imported or inherited
by the source file's package at compile time, but not at load time, then
the wrong SYM will be referenced.
[I don't see how this solves the problem I described above with the FOO
and BAR packages. Seems to me that SYM would end up in the FOO package
alright, but so would an unqualified symbol, say SYM2. But SYM2 ought
to end up in BAR, the current package at load time. To summarize:
source file, compiled when FOO is current package:
FOO::SYM1
SYM2
fastload file, loaded when BAR is current package:
FOO::SYM1 ; Better end up in FOO.
SYM2 ; Better end up in BAR.
]
∂12-Apr-85 0704 FAHLMAN@CMU-CS-C.ARPA PROBE-FILE
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Apr 85 07:03:54 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 12 Apr 85 10:03:47-EST
Date: Fri, 12 Apr 1985 10:03 EST
Message-ID: <FAHLMAN.12102566546.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Nick Gall <Gall@MIT-MULTICS.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: PROBE-FILE
In-reply-to: Msg of 12 Apr 1985 00:21-EST from Nick Gall <Gall at MIT-MULTICS.ARPA>
A problem with your suggestion is that in most of the distributed,
heterogenous environments that people are moving to now, there's not a
clear separation between syntactic and semantic problems with a
namestring. Add a unix system to your search-list, and suddenly the
slash character turns from syntactic garbage to an essential part of an
address. So I wouldn't want the error/no-error distinction to depend on
whether the string was ill-formed or merely happened not to point to a
reasonable place in the current environment.
- Scott
∂12-Apr-85 1103 KMP@SCRC-STONY-BROOK.ARPA Probe-file and errors
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 Apr 85 11:03:18 PST
Received: from SCRC-RIO-DE-JANEIRO by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 214170; Fri 12-Apr-85 13:58:44-EST
Date: Fri, 12 Apr 85 13:58 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Probe-file and errors
To: dzg@CMU-CS-SPICE.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <6595.160879383.>
Message-ID: <850412135811.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Thu 11 Apr 85 15:41:18-EST
From: dzg@CMU-CS-SPICE.ARPA
What seems to be impossible, for some reason, is to make simple things simple.
... My code just wants to do
(cond ((probe-file "/usr/foo/bar")
...)
((probe-file "/user/may/be")
...)
((probe-file "/yet/another/one")
...)
(t
... cannot find it. Bye. ...))
Simple as that. I do not (DO NOT!) want to handle an error...
In LispM lisp, you would write:
(cond ((ignore-errors (probe-file "/usr/foo/bar"))
...)
...etc)
It seems to me that this is not an unreasonable thing and has the
advantage of making it nicely explicit that you in fact don't care
what happens in the failing cases.
IGNORE-ERRORS is not in my error proposal but could be added.
-kmp
∂12-Apr-85 1416 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: PROBE-FILE
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 12 Apr 85 14:15:56 PST
Date: Fri, 12 Apr 85 17:11 EST
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: Re: PROBE-FILE
To: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 12 Apr 85 10:03 EST from "Scott E. Fahlman"
Message-ID: <850412221124.132617@MIT-MULTICS.ARPA>
Date: 12 April 1985 10:03 est
From: Scott E. Fahlman <Fahlman at CMU-CS-C>
Subject: PROBE-FILE
A problem with your suggestion is that in most of the distributed,
heterogenous environments that people are moving to now, there's not a
clear separation between syntactic and semantic problems with a
namestring. Add a unix system to your search-list, and suddenly the
slash character turns from syntactic garbage to an essential part of an
address. So I wouldn't want the error/no-error distinction to depend on
whether the string was ill-formed or merely happened not to point to a
reasonable place in the current environment.
- Scott
My suggestion is based on the `clear separation' that the CLRM itself
makes between an `ill-formed' namestring and a namestring that is
well-formed but meaningless. This distinction is explicitly made in the
definition of PARSE-NAMESTRING (pg. 414): An error is signalled if the
[name]string does not consist entirely of the representation of a
pathname.
1. IF one agrees that PARSE-NAMESTRING signals an error when given an
ill-formed namestring, but does not signal an error when given a
well-formed namestring (regardless of its meaningfulness)
2. AND IF one agrees that any function (call it FOO) that takes a
namestring argument implicity calls PARSE-NAMESTRING (perhaps via
PATHNAME) to transform the namestring into a pathname
3. AND IF one agrees that any error signalled by the implicit call to
PARSE-NAMESTRING is propagated by FOO
THEN one should agree that PROBE-FILE must signal an error if (but not
necessarily only if) given an ill-formed namestring.
My suggestion boils down to making points 2 and 3 EXPLICIT in the CLRM,
based on my belief that these two points are already IMPLIED in the
CLRM.
P.S. I'm not sure I understand the comment about adding a unix system
to my search list, but I believe that namestrings are usually parsed
`with reference to a particular file name syntax of several avaialable
in the implementation' (pg. 414). And the Host component is `used to
determine the syntax convention' (pg. 414). Doesn't this take care of
the slashes?
∂12-Apr-85 1755 JLW Two PROBE-FILE questions
To: RAM@CMU-CS-C.ARPA
CC: common-lisp@SU-AI.ARPA
In-reply-to: your Msg of 10-Apr-85 14:56 EST
I think you've elucidated, in the second paragraph, the main difficulty
of a non-opening probe-file. True, one of these problems isn't unique to
probe-for-output -- that of asynchronous change in th file system by some
other process -- but that doesn't lessen the importance. The second one
(that I was thinking of) is simply the problem of TRUENAME -- unless you
actually open-for-output, then there's a high probability that you can't
find exactly th fully-qualified pathname that the file system would have
returned. Version numbers is one of the problems; following links may be
another; and finaly (for me, at least) there is the confusion as to whether
the result of a direction-output call is a "file name" or merely a very
hypothetical pathname -- e.g., "this pathname is NOT a file, but if you
had called open instead of probe-file, then this would have been the name
of the file so opened".
Say, Rob, do you get the same sense that I do that something went astray
with this discussion? In my note of 9-Apr-85, I thought I was arguing
the case for using OPEN directly, rather than preceeding it by a call
to PROBE-FILE; this led to the suggestion to continue the development
of "signals" *** in order to field the file-not-found error from OPEN ***
But it looks like the discussion centered around fielding error signals
from probe-file. foo.
If I wasn't clear about my bias before, let me state it now; I don't see
much use for direction-output for probe-file. Let probe-file remain a
simple function, such as DZG wants, with an informational nature, and
let us discourage users from imagining it to be some kind of file system
semaphore.
-- JonL --
∂12-Apr-85 1822 card.pa@Xerox.ARPA Re: Arg cont checking, optionals, keywords, etc
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 12 Apr 85 18:04:51 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 APR 85 18:01:41 PST
Date: 12 Apr 85 18:01 PST
From: card.pa@Xerox.ARPA
Subject: Re: Arg cont checking, optionals, keywords, etc
In-reply-to: Jon White <JLW@SU-AI.ARPA>'s message of 09 Apr 85 17:22 PST
To: JLW@SU-AI.ARPA
cc: Card.pa@Xerox.ARPA, bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA
I believe the Common Lisp syntax untimately derives from Muddle. There
is of course virtue, if the change were to occur in Interlisp-D,
adopting a syntax compatible with Common Lisp.
For my taste, however, I would prefer one compatible with Interlisp-D
DECL DLAMBDAs as in my earlier examples. This allows (at the option of
the programmer) stronger error checking than argument counting alone as
well as self-documentation of the variables. Both syntaxes could be
available in this case and could compile to the same code.
Stu
∂12-Apr-85 1929 FAHLMAN@CMU-CS-C.ARPA Common Lisp should use lexical scoping
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Apr 85 19:29:15 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 12 Apr 85 22:29:23-EST
Date: Fri, 12 Apr 1985 22:29 EST
Message-ID: <FAHLMAN.12102702302.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: masinter.pa@XEROX.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Common Lisp should use lexical scoping
In-reply-to: Msg of 12 Apr 1985 19:09-EST from masinter.pa at Xerox.ARPA
Larry,
Maybe I misunderstand what you mean by "lexical scoping" of packages,
since your proposal was not spelled out in detail. But here's what I am
worried about:
When we're speaking of the scope variables, lexical scoping means that
the scope of the variable is one contiguous chunk in the file being
read, and once you leave the lexical block you can never again get hold
of that variable by using its name (though function closures defined
within the block can still get at the variable). You cannot sneak in
one more function later that refers to the same X. That's awkward at
times, but also an advantage, since the compiler can be sure that after
it has reached the end of a block, it knows all about how a lexical
variable in that block can be referenced.
In lexically scoped packages, presumably this property would be
preserved. So you would have to load all of the contents of a package
in a single chunk, even if this stuff comes form several files.
After you exit the lexical scope of a package, presumably you could
never again go back and add a new symbol to it, though I suppose the
reader could still refer to existing symbols in that package.
(Otherwise, the whole package could just be thrown out after you exit
the scope.)
That might possible make sense if you are thinking only of reading a
bunch of existing files into the Lisp, but when you are developing code
that perhaps lives in several packages, you need to be able to bounce
back and forth between packages, adding new stuff to each package. I
don't see any way to do this without some sort of dynamic scoping of
packages.
Perhaps I have totally misunderstood your proposal?
-- Scott
∂13-Apr-85 1410 HANDERSON@CMU-CS-C.ARPA Common Lisp should use lexical scoping
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 13 Apr 85 14:10:28 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Sat 13 Apr 85 17:10:36-EST
Date: Sat, 13 Apr 1985 17:10 EST
Message-ID: <HANDERSON.12102906405.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Cc: common-lisp@SU-AI.ARPA, masinter.pa@XEROX.ARPA
Subject: Common Lisp should use lexical scoping
In-reply-to: Msg of 12 Apr 1985 22:29-EST from Scott E. Fahlman <Fahlman>
I think that the reason for this property (that an environment is created once
and never altered) is so that you can assign positions in a vector to the
variables, for runtime efficiency. If you have an alist, there's no reason why
you couldn't create a scheme where you could push things onto it etc. and have
it do the right thing.
For interning symbols, you could probably afford to do a hairy loadtime search
to find where the symbol is, since once you find it, you have this physical
object to refer to. The package specification would just look something like a
pathname. Of course, I think one of the problems with packages might be that
adding a variable FOO to a shadowing packages doesn't shadow an already-loaded
symbol. I dunno.
-- Steve
∂15-Apr-85 1712 Moon@SCRC-QUABBIN.ARPA Common Lisp should use lexical scoping
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 15 Apr 85 17:12:26 PST
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 153822; Mon 15-Apr-85 15:33:51-EST
Date: Mon, 15 Apr 85 15:30 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Common Lisp should use lexical scoping
To: masinter.pa@XEROX.ARPA, Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>,
Steven <Handerson@CMU-CS-C.ARPA>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 11 Apr 85 21:42-EST from masinter.pa@Xerox.ARPA,
<FAHLMAN.12102702302.BABYL@CMU-CS-C.ARPA>,
<HANDERSON.12102906405.BABYL@CMU-CS-C.ARPA>
Message-ID: <850415153047.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
The subject of this conversation is rather a misnomer. I believe that
what you are really suggesting is that packages should affect the
mapping from symbols to named entities (variables, functions, etc.)
rather than the mapping from print-names to symbols.
That is certainly a reasonable position to take, and some other
languages (Scheme, T, Lisp 2) have taken it with varying degrees of
success. As I recall, we considered this when designing Common Lisp but
decided that the technical risk was too high. One thing to think about
is that there are many different mappings from symbols to named
entities, some of them implemented by user programs; the "et cetera" in
my first paragraph is hiding a multitude of things. Sticking to Common
Lisp, there are data types, defstructs, declarations, properties, and
keywords. Going outside of Common Lisp brings in such named objects as
flavors, messages, editor commands, and any number of user-defined
spaces of named objects. Which of these should be affected by packages
and which should not? And should the implementation of a mapping by the
property list or by some other mechanism be exposed in the semantics of
that mapping with respect to packages?
T has some reasonable responses to these issues, and I think if Common
Lisp were being designed in 1987 we might decide differently after
studying languages such as T and how their users use them. But Common
Lisp was designed in 1982. We decided to go with the well-understood
package philosophy that the Lisp machine had been using since about
1978, substantially redesigned to fix its well-understood bugs without
radically changing the whole philosophy. It's hard to achieve
perfection in this mortal vale. For additional insight, see the James
Madison quotation on the second page of the manual.
∂15-Apr-85 1713 Moon@SCRC-QUABBIN.ARPA A-Packaging we will go...
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 15 Apr 85 17:12:52 PST
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 153861; Mon 15-Apr-85 17:00:44-EST
Date: Mon, 15 Apr 85 16:57 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: A-Packaging we will go...
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 12 Apr 85 10:00-EST from greek at DEC-HUDSON
Message-ID: <850415165739.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 12 Apr 85 10:00:19 EST
From: greek@DEC-HUDSON
[My new comments are in square brackets -- Paul.]
Well, Mr. Moon, I gave your comment some thought. It was a bit terse,
but perhaps this is what you meant:
What happens if a macro calls a function during the expansion of a
macro call? If that function is in, say, the "USER" package, and the
compiler were to make the current package "SPECIAL-COMPILER-PACKAGE-
THAT-NO-ONE-ELSE-USES", then indeed the function wouldn't be found
at compile time.
What if the function was in the LISP package? Does your special compiler
package inherit from there or doesn't it? If it doesn't, macros can't
run. If it does, you can't tell whether a symbol came from there via
package prefix or via inheritance.
[Well, as you say, it must inherit from the LISP package.
But why do I care whether the compiler can tell that the symbol had
a package prefix or inherited the symbol? The fact is that the symbol
is in the LISP package, so the fast loader better find it there.]
I thought the whole point of your suggestion for a special compiler package
was that you cared.
But then again, it wouldn't be found if the user didn't happen to be
in the "USER" package when compiling the program. If the program
must be compiled in the "USER" package, it ought to do an IN-PACKAGE
at the top.
If I read you wrong, please let me know.
By the way, here's what VAX LISP currently does: If the compiler goes
to dump a symbol which is in the current package (not any special
compiler package), then it dumps it without a package. This means
it will be loaded into the current package at the time of loading.
In other words, it does the same thing as PRINT. This is what our compiler
does, too.
[But do we agree that's correct?]
I believe that it is inherently the best thing that can be done, if you grant
the compiler uses the Lisp READ function as its lexical analyzer.
I don't think this is quite right, since it means that if I'm in
the "FOO" package when I compile, and I say FOO::SYM, and then I'm
in "BAR" when I load it, SYM will end up in "BAR" rather than "FOO".
To avoid this problem, I think you need the special compiler package.
A better approach is for the compiler to tell the loader what the value
of *PACKAGE* was when the file was compiled. If the loader binds
*PACKAGE* to the same value (that is, to a package with the same name)
when the file is loaded, symbol names in the compiled file will be
interpreted as the compiler intended when it dumped them. This approach
works well for us. Of course the user can get into arbitrary amounts of
trouble by changing package definitions between the time a file is compiled
and the time it is loaded, but that is inherently unavoidable. For instance,
if the source file referenced FOO::SYM, and SYM was imported or inherited
by the source file's package at compile time, but not at load time, then
the wrong SYM will be referenced.
[I don't see how this solves the problem I described above with the FOO
and BAR packages. Seems to me that SYM would end up in the FOO package
alright, but so would an unqualified symbol, say SYM2. But SYM2 ought
to end up in BAR, the current package at load time. To summarize:
source file, compiled when FOO is current package:
FOO::SYM1
SYM2
fastload file, loaded when BAR is current package:
FOO::SYM1 ; Better end up in FOO.
SYM2 ; Better end up in BAR.
]
This problem derives entirely from the (doomed) attempt to compile a file
in one package and load it into another. You cannot expect reasonable
results from this. Hence my suggestion for the loader to ensure that the
file is loaded into the correct package. If FOO was not the correct
package, why did you compile it in that package? Or, to ask the question
another way, why did your compiler compile it in the wrong package? This
relates to the other discussion about the file attribute convention (-*-).
This piece of mail is getting rather long. I suggest that if we need to
discuss this further, we should prune it. I myself don't have anything
further to say.
∂15-Apr-85 1718 DLW@SCRC-STONY-BROOK.ARPA probe-file
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Apr 85 17:17:43 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 214940; Mon 15-Apr-85 16:10:40-EST
Date: Mon, 15 Apr 85 16:10 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: probe-file
To: masinter.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 11 Apr 85 22:27-EST from masinter.pa@Xerox.ARPA
Message-ID: <850415161032.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: 11 Apr 85 19:27 PST
From: masinter.pa@Xerox.ARPA
I understand your point and disagree. We gave this a great deal of
thought when we were designing our error system.
Note that there is some mutual property of these two functions, in that
either is relatively simple to implement in terms of the other, given an
error system of the imagined complexity of the Common Lisp error system.
Indeed. In Symbolics Common Lisp, probe-file-that-generates-errors is
just probe-file, and probe-file-without-errors can be defined as
(defun probe-file-without-errors (pathname)
(condition-case (error-object)
(probe-file pathname)
(error (values nil error-object))))
Which would you prefer to have in the "standard" Common Lisp? Both?
Which would fit well with "most programs"? Which would "most
programmers" naturally chose if they had both available in their
library?
Given a good error-handler system such as ours, I think the
"generates-errors" is the one that should be provided. In my
experience, doing it the way you suggest (returning error codes) means
that either every function call has to be surrounded by all these forms
to receive the value and test it and so on, or else the programmers get
lazy, leave that stuff out, and when the error conditions happen the
programs plow right along doing all kinds of incorrect things. In our
system, if the programmers have something in particular that they'd like
to do in the face of errors, they can express these things concisely and
clearly, and if they aren't thinking about errors or are just lazy, then
unanticipated errors put the program into an interactive debugger before
they go off and cause more damage.
We've been using this error system for a couple of years and are quite
happy with it.
∂15-Apr-85 1718 DLW@SCRC-STONY-BROOK.ARPA Common Lisp should use lexical scoping
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Apr 85 17:18:14 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 214948; Mon 15-Apr-85 16:24:26-EST
Date: Mon, 15 Apr 85 16:24 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Common Lisp should use lexical scoping
To: masinter.pa@XEROX.ARPA, Common-Lisp@SU-AI.ARPA
Message-ID: <850415162426.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: 11 Apr 85 18:42 PST
From: masinter.pa@Xerox.ARPA
Of course, I'm not talking about the scoping of variables, but rather of
packages. The "package" of a piece of code is really a lexical property
of the code. The fact that packages are dynamic in extent rather than
lexical has led to almost all of the problems in defining what happens
to packages and the compiler.
Packages aren't dynamic in extent. They have indefinite extent. See
Chapter 3. I'm not sure that the analogy to the "lexical versus
dynamic" dichotomy is a very good way of looking at this, since nothing
in question has dynamic extent. ("Dynamic scope" really means
indefinite scope and dynamic extent.)
In any case, I'm wondering the same things as Scott. Could you please
elaborate on your proposal?
∂15-Apr-85 1719 DLW@SCRC-STONY-BROOK.ARPA PROBE-FILE
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Apr 85 17:18:32 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 214964; Mon 15-Apr-85 16:55:53-EST
Date: Mon, 15 Apr 85 16:55 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: PROBE-FILE
To: KMP@STONY-BROOK.SCRC.Symbolics.COM, greek@DEC-HUDSON.ARPA,
common-lisp@SU-AI.ARPA
Message-ID: <850415165553.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Thu, 11 Apr 85 14:26 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
So, perhaps surprisingly, I'm suggesting that using error signalling may
simplify (rather than complicate) the look of code and maybe people with
hairy-construct phobias will actually like this...
-kmp
I agree completely and strongly with Kent's point. In my earlier reply
to Masinter, this is what I was trying to get at.
∂15-Apr-85 1843 FAHLMAN@CMU-CS-C.ARPA probe-file
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Apr 85 18:43:33 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 15 Apr 85 21:43:39-EST
Date: Mon, 15 Apr 1985 21:43 EST
Message-ID: <FAHLMAN.12103480407.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: probe-file
In-reply-to: Msg of 15 Apr 1985 16:10-EST from Daniel L. Weinreb <DLW at TENEX.SCRC.Symbolics.COM>
As I said earlier, it probably is best to handle this on an ad hoc basis
until we get an error system defined. We're not going to make much
progress as long as some of us view the error system as warm and fuzzy
and others of us view it as something to be avoided at all costs.
-- Scott
∂16-Apr-85 0740 greek@DEC-HUDSON Packages and the Compiler
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 16 Apr 85 07:40:28 PST
Date: Tue, 16 Apr 85 10:40:28 EST
From: greek@DEC-HUDSON
Subject: Packages and the Compiler
To: common-lisp@su-ai
Yes, I guess we've exhausted this subject pretty much. I think compiling
in one package and loading into another is useful. I always debug a
new subsystem, say FORMAT, by working in a temporary FORMAT package
and then finally loading the file into SYSTEM and running the tests.
Why should I have to recompile it again to do that?
Anyway, we basically agree that compiling in one package and loading
into another is ill-defined.
- Paul
∂16-Apr-85 1433 DLW@SCRC-STONY-BROOK.ARPA Compilation and package system
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Apr 85 14:33:03 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 215535; Tue 16-Apr-85 17:20:07-EST
Date: Tue, 16 Apr 85 17:20 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Compilation and package system
To: Wholey@CMU-CS-C.ARPA
cc: Common-lisp@SU-AI.ARPA, perdue%hplabs.csnet@CSNET-RELAY.ARPA
In-Reply-To: <WHOLEY.12101913081.BABYL@CMU-CS-C.ARPA>,
The message of 9 Apr 85 22:14-EST from Wholey@CMU-CS-C.ARPA,
<WHOLEY.12101913081.BABYL@CMU-CS-C.ARPA>,
The message of 10 Apr 85 22:33-EST from Moon@STONY-BROOK.SCRC.Symbolics.COM,
<850410223354.7.MOON@EUPHRATES.SCRC.Symbolics.COM>,
The message of 10 Apr 85 23:51-EST from Wholey@CMU-CS-C.ARPA,
<WHOLEY.12102192890.BABYL@CMU-CS-C.ARPA>,
The message of 11 Apr 85 00:35-EST from KMP@STONY-BROOK.SCRC.Symbolics.COM,
<850411003554.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<WHOLEY.12101913081.BABYL@CMU-CS-C.ARPA>,
The message of 11 Apr 85 03:41-EST from Wholey@CMU-CS-C.ARPA,
<WHOLEY.12102234761.BABYL@CMU-CS-C.ARPA>
Message-ID: <850416172034.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
To summarize this discussion, the desired solution that would satisfy
everyone would have the following properties:
(1) Package specifications should not use the -*- stuff at all, because
there's nothing about -*- in the Common Lisp manual. Not only does this
make it easier to port programs, but it's necessary to allow the
building of portable programs that understand files of Common Lisp code
(e.g. cross referencers). It's OK to have the -*- in ADDITION to the
portable forms that specify package setups, but it's purely optional
from the point of view of the Common Lisp evaluator and compiler.
(Possibly we could back off and have a yellow-pages package that
Symbolics provides and other implementations pick up.)
(2) The editor needs as much information about packages as the compiler
and the loader. All programs that read Lisp forms from files must get
the package information from the same place, and work consistently.
Furthermore, it is out of the question for you to have to manually
evaluate forms out of the buffer before you can edit properly.
(3) It should not be required that complex package setups be in their own
file, since you want to be able to use packages flexibly even in
programs that fit in one file. Use of packages shouldn't force you to
have to split your program into many files, with associated pain in
copying them, etc, etc.
(4) If Symbolics Common Lisp and its editor are to work correctly on
ported unmodified Common Lisp source files, it must be prepared to deal
with CMU files, which use -*- lines that refer to packages that aren't
created until that very file is evaluated. Right now, the CLCP user
at CMU gets an error. Strictly speaking, the program is valid Common
Lisp, because Common Lisp doesn't ever look inside comments, and so
the CLCP is technically in error.
As far as I can tell, the only way to meet the first three constraints
is to require the editor to parse through the entire file, finding all
of the package-related forms such as IMPORT, when the file is read in.
It's a bit harder than that, since those forms might be inside of
EVAL-WHEN forms. Or COND forms. Or there might be a function defined
in the file and later called at top-level that does an IMPORT. Worse
yet, the "package environment" might be different at different parts of
the file, as various package-related forms are sprinkled among the
function definitions.
I don't think this is feasible.
Zetalisp has basically taken the stance that each file has exactly one
"package environment" that's the same throughout the file, and the
information that sets up this environment is essentially declarative,
rather than imperative. These restrictions have not turned out to be a
problem, based on large volumes of sophisticated code turned out over
several years. In exchange for them, we get point (2) above. Perhaps
it is our disagreement over (2)'s importance that is really at the
bottom of this discussion.
∂16-Apr-85 1556 Moon@SCRC-STONY-BROOK.ARPA Compilation and package system
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Apr 85 15:56:21 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 215600; Tue 16-Apr-85 18:56:32-EST
Date: Tue, 16 Apr 85 18:53 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Compilation and package system
To: Common-lisp@SU-AI.ARPA
References: <850416172034.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <850416185341.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Side-comment: I know of three other (besides Symbolics) Lisps that use the
-*- convention for file attributes and have representatives on this mailing
list. I'm mildly surprised that none of them have spoken up so far.
∂16-Apr-85 1808 DD60@CMU-CS-A.ARPA Package system
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 16 Apr 85 18:08:32 PST
Date: Tue, 16 Apr 85 20:58 EST
From: David.Dill@CMU-CS-A.ARPA (L170DD60)
To: common-lisp@su-ai.arpa
Subject: Package system
Message-Id: <16Apr85.205840.DD60@CMU-CS-A.ARPA>
One must use the package system in a very restricted way in order for
compilers, editors, and other (mostly not-yet-existent) program
transformation tools to do reasonable things. During the design of the
package system, I don't think that anyone was under the delusion that
arbitrary common lisp code sequences that manipulate the package system
(or do a large number of other things) would behave the same compiled
as interpreted.
The package chapter should probably have had more to say about this,
and should not have documented the "conventional use of the package
system", which is very important for preserving sanity, in the
"example" subsection. Somewhere, relatively simple restrictions on the
use of the package system should be precisely described, so that users
can distinguish code that will work from code that might not, and
portable code from non-portable code.
Why does the editor problem have to be so hard? It seems to me that if
programmers would make the call to in-package be the first lisp form in
the file, the editor would have no more trouble setting up the proper
package context than it would with the magic comment crock.
I also think that if complex package structures turn out to be really
necessary (which I am not convinced of), a number of standard ways to
deal with them could be developed so that a user could be reasonably
assured of not getting screwed, AND editors, compilers, and so on,
would be able to understand what is going on, all within CL.
∂16-Apr-85 1921 FAHLMAN@CMU-CS-C.ARPA Compilation and package system
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 16 Apr 85 19:21:13 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 16 Apr 85 22:20:44-EST
Date: Tue, 16 Apr 1985 22:20 EST
Message-ID: <FAHLMAN.12103749301.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "Daniel L. Weinreb" <DLW%scrc@MIT-MC.ARPA>
Cc: Common-lisp@SU-AI.ARPA
Subject: Compilation and package system
(1)... It's OK to have the -*- in ADDITION to the
portable forms that specify package setups, but it's purely optional
from the point of view of the Common Lisp evaluator and compiler.
Right!
I'm not sure what all gets tangled up in the Zetalisp compiler when
CLCP is turned on, but maybe something like the following would fly:
Use a slightly different notation in the comment line for each of the
three cases of interest:
A. This is a Zetalisp-style file comment, and the editor can get all
that it needs right here in this comment line.
B. This is vanilla Common Lisp, but it follows the convention (as in
Zetalisp and the vast majority of Spice Lisp code) that the whole file
fits into one package environment that is set by in the first few forms
in the file. The first time the user asks for some form in the buffer
to be read into Lisp or compiled, the system would first execute these
opeing forms, stopping when it hits something non-package-related.
(Or we could use some explicit marker telling the system when to stop.)
In this case, if there is a "Package:Foo" in the -*- line, that is
shorthand for "Don't bother reading anything in the file -- all you need
to know is that the first statement is a simple (in-package "FOO").
C. This is vanilla Common Lisp with no guarantees about the package
structure in the file. If the user actually asks for something in the
buffer to be read into Lisp or compiled, the system must first read
everything up to that point in order to be sure that the environment is
right. The system could query him to see if he wants to go through with
this.
Note that this is not an extension to Common Lisp, but merely a
convention that those implementations with embedded Emacs-like editors
might adopt to make code-sharing easier.
-- Scott
∂17-Apr-85 0800 DLW@SCRC-QUABBIN.ARPA Package system
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 Apr 85 08:00:10 PST
Received: from SCRC-CHICOPEE by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 154375; Wed 17-Apr-85 11:00:10-EST
Date: Wed, 17 Apr 85 11:01 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Package system
To: David.Dill@CMU-CS-A.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <16Apr85.205840.DD60@CMU-CS-A.ARPA>
Message-ID: <850417110105.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Tue, 16 Apr 85 20:58 EST
From: David.Dill@CMU-CS-A.ARPA (L170DD60)
Why does the editor problem have to be so hard? It seems to me that if
programmers would make the call to in-package be the first lisp form in
the file, the editor would have no more trouble setting up the proper
package context than it would with the magic comment crock.
What if there are some IMPORT forms following the IN-PACKAGE form?
What if there are some IMPORT forms 3/4 of the way into the file?
How does the editor know when to stop scanning for such forms?
∂17-Apr-85 0841 GSB@MIT-MC Re: Compilation and package system
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Apr 85 08:40:54 PST
Date: Wed,17 Apr 85 11:40:48 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: Re: Compilation and package system
To: Moon@SCRC-STONY-BROOK
cc: Common-lisp@SU-AI
Message-ID: <[MIT-MC].458008.850417.GSB>
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Side-comment: I know of three other (besides Symbolics) Lisps that use the
-*- convention for file attributes and have representatives on this mailing
list. I'm mildly surprised that none of them have spoken up so far.
I had thought i had sent a request to my PR department to send the
standard file-attribute-list blurb off to the common-lisp people, but
they must have slipped up. Oh well -- you know what it's like in
these huge organizations.
NIL uses file attribute lists quite heavily. The method in which they
are defined is (or at least was a year ago) an extension of how it was
done in Zetalisp, too. They are most commonly used for package
specification, and secondarily for specifying the reader syntax, since
NIL has been incrementally converted to common-lisp reader syntax.
(This doesn't count "editor mode", but that's almost invariably "lisp"
for lisp code anyway.)
∂17-Apr-85 1722 masinter.pa@Xerox.ARPA "lexical" packages
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 17 Apr 85 17:22:19 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 APR 85 17:20:45 PST
Date: 17 Apr 85 17:20 PST
From: masinter.pa@Xerox.ARPA
Subject: "lexical" packages
To: Common-Lisp@SU-AI.ARPA
Rebuttals:
Fahlman:
"When we're speaking of the scope variables, lexical scoping means that
the scope of the variable is one contiguous chunk in the file being
read, and once you leave the lexical block you can never again get hold
of that variable by using its name (though function closures defined
within the block can still get at the variable). You cannot sneak in
one more function later that refers to the same X. That's awkward at
times, but also an advantage, since the compiler can be sure that after
it has reached the end of a block, it knows all about how a lexical
variable in that block can be referenced."
Of course this isn't true, lest we be reduced to using core dumps to
debug. Of course, the debugger and the environment can reasonably be
expected to provide a way to access "lexical" variables. But such
mechanisms are part of CLTE rather than CLTL. The language has semantics
with invariants (if you (setq x --) here and call a function, you can
still expect x to have the same value), and the environment gives you
tools to break those invariants. Thus, while I propose making the
"package" a lexical property (more on that later), any reasonable
environment would provide ways of dynamically switching.
Moon:
"T has some reasonable responses to these issues, and I think if Common
Lisp were being designed in 1987 we might decide differently after
studying languages such as T and how their users use them. But Common
Lisp was designed in 1982. We decided to go with the well-understood
package philosophy that the Lisp machine had been using since about
1978, substantially redesigned to fix its well-understood bugs without
radically changing the whole philosophy. It's hard to achieve
perfection in this mortal vale. For additional insight, see the James
Madison quotation on the second page of the manual."
This is one of the weakest arguments to make -- it can be applied to any
of the discussions on this or any of the other mailing lists about
Common Lisp. If there's no chance to remove some of the mistakes in
Common Lisp, there seems to be no grounds for further discussion.
- - - - - - -
Restatement of proposal:
Packages should rightfully be lexical (determined by character sequences
in the file) rather than a dynamic (determined by what you've recently
executed).
Let me make a specific proposal:
Just as (DECLARE --) is a special form, and "it is an error" to attempt
to evaluate a declaration, I propose that
provide, in-package, shadow, export, require, use-package, import
all be documented as as special forms; they may only occur at the
beginnings of files. They are special markers that load, the compiler,
and the editor etc. can look for. (The wording for this can be taken
almost directly from the documentation of "declare" in CLTL p 153).
This turns what was formally a convention into a requirement. It means
that editors/file packages/etc. can actually look at a file and
determine (by scanning the beginning of the file) what packages might be
used/exported/etc. by the file. It makes illegal most of the odd (bad
programming practice) things that can go wrong with the package system.
It removes the requirement that the whole file be read, parsed and
executed in order to get a particular function. Many of the caveats in
the package section could be removed.
For those who already have an implementation of the current package
mechanism, the burden of this new scheme is minimal -- they can add
error checking, but need not.
∂17-Apr-85 1752 FAHLMAN@CMU-CS-C.ARPA "lexical" packages
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Apr 85 17:51:50 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 17 Apr 85 20:51:55-EST
Date: Wed, 17 Apr 1985 20:51 EST
Message-ID: <FAHLMAN.12103995276.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: masinter.pa@XEROX.ARPA
Cc: Common-Lisp@SU-AI.ARPA
Subject: "lexical" packages
In-reply-to: Msg of 17 Apr 1985 20:20-EST from masinter.pa at Xerox.ARPA
Larry,
OK, now I think I understand what you're saying, as far as it goes.
This is very similar to what the Symbolics people were just arguing for:
that all of the package stuff happens at the start of a file, and the
"scope" within which a package is the default for the reader is one
file.
I'm basically in sympathy with the idea that you don't change the
package environment in the middle of a file. Right now, I can't think
of any situation in which I'd really want to change packages within a
file. So far, so good.
I think that I would often want to load N files, some of which go into
package A and some of which go into package B in any order. There's no
problem with this as long as each file going into a certain package has
identical (or maybe just compatible) package stuff at the start. To me,
this isn't exactly lexical, as I understand the term, but there's no
point in quibbling about terminology.
What I don't understand about your proposal is how one deals with
input to the reader that is not in the form of a file, with its natural
lexical boundaries. How do we handle terminal input, input from streams
whose source is unknown to the Lisp, and so on, if not dynamically?
If the essence of your proposal is that we handle packages more as less
as we do now, except that IN FILES the package forms must all occur at
the start and the system can take their scope to be the whole file,
that's worth some careful study. It certainly is good style in all the
situations I can think of, so maybe enforcing it wouldn't be so bad.
However, this sort of messes up the abstraction that Lisp just sucks
streams into the reader and that the reader doesn't care where the stuff
is coming from.
-- Scott
∂18-Apr-85 1013 DLW@SCRC-STONY-BROOK.ARPA Compilation and package system, an addendum
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Apr 85 10:10:21 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 216975; Thu 18-Apr-85 13:09:26-EST
Date: Thu, 18 Apr 85 13:10 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Compilation and package system, an addendum
To: TIM@MC.MIT
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[MIT-MC].459123.850418.TIM>
Message-ID: <850418131043.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Thu,18 Apr 85 01:22:26 EST
From: Tim McNerney <TIM@MIT-MC>
Yes, there could be an arbitrary amount of hair, but there is a big
difference between assuming that an entire file will be read in the
package declared by the -*- line and supporting lusers who want to
generate the screw cases you allude to above. Once the package
environment is established, simply having the ZMACS keep a package
attribute for each section will support editing files like patch files
which need to be read in a number of different packages.
You seem to be saying that the high cost can be avoided by not
supporting "lusers" who generate the "screw cases". In other words, the
editor should not actually parse the entire file, because that costs too
much, and it's OK if it does the wrong thing for the screw cases. I
could be convinced of that principle. So, what is your counterproposal?
Exactly what will the editor do when a file is read in, such that it
does all the right things except in "screw cases"? How does it know
where to stop parsing?
And if you expect the editor to work correctly on files like patch
files, with different package environments in each section, then you
certainly do need to scan the entire file. If you disagree, what's
your countersuggestion?
∂18-Apr-85 1253 REM%IMSSS.#Pup@SU-SCORE.ARPA What is a "file"? Lexical package usage?
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 18 Apr 85 12:52:55 PST
Received: from IMSSS by Score with Pup; Thu 18 Apr 85 12:39:03-PST
Date: 18 Apr 1985 1235-PST
From: Rem@IMSSS
Subject: What is a "file"? Lexical package usage?
To: COMMON-LISP%SU-AI@SCORE
A file signals its end by an end-of-file marker of some kind (I'd have to
look in the CL manual to remind myself what it is in CL). The beginning of
a file is indicated by being right after you have done some kind of OPEN,
and is lexical extent is from that point unti the end-of-file marker occurs.
Perhaps if lexical packages are implemented, other streams can issue package
and other start-of-file stuff right after they are "opened" whatever that
means for the stream, and can signal the end of a lexical segment by an
end-of-file marker? For terminal-input and other infinite streams, the
interpretor can immediately re-open them after noting the lexical break
caused by end-of-file, flushing any info it had about the package state
from the just-now-closed segment and preparing to accept new package
declarations from the new segment to arrive next on the re-opened stream.
Would that solve the problem with "IN A FILE" being a special case?
-------
∂18-Apr-85 1847 Moon@SCRC-STONY-BROOK.ARPA "lexical" packages
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Apr 85 18:47:32 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 217657; Thu 18-Apr-85 21:47:29-EST
Date: Thu, 18 Apr 85 21:44 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: "lexical" packages
To: masinter.pa@XEROX.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 17 Apr 85 20:20-EST from masinter.pa at XEROX
Message-ID: <850418214445.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I understand now that what you meant was not at all what you seemed to be saying.
This will bear some thinking about. More from me on this later, perhaps.
∂18-Apr-85 1911 KMP@MIT-MC "lexical" packages
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Apr 85 19:07:24 PST
Date: Thu,18 Apr 85 22:01:15 EST
From: Kent M Pitman <KMP@MIT-MC>
Subject: "lexical" packages
To: Common-Lisp@SU-AI, Masinter.PA@XEROX, Fahlman@CMU-CS-C,
Moon@SCRC-STONY-BROOK
Message-ID: <[MIT-MC].460578.850418.KMP>
I'd prefer to see the sort of lexicality I think you're talking about
handled through OPEN rather than READ, but agree it's worth thinking
about..
∂19-Apr-85 2128 DLW@SCRC-STONY-BROOK.ARPA "lexical" packages
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 19 Apr 85 21:28:19 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 218502; Sat 20-Apr-85 00:28:00-EST
Date: Sat, 20 Apr 85 00:30 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: "lexical" packages
To: masinter.pa@XEROX.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 17 Apr 85 20:20-EST from masinter.pa@XEROX.ARPA
Message-ID: <850420003003.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
If you recall my four-point message (of Tue, 16 Apr 85 17:20 EST,
replying to Skef), your proposal indeed meets all four points. It also
solves the editor-scanning problem, since as soon as the editor sees any
normal forms it can stop scanning. It also solves all those other
problems I mentioned about evaluating those things inside various forms
or functions, since they can no longer appear there.
Only one problem comes to mind, and it's not hard to solve. Sometimes
you have a system made up of many files that are all in the same
package, and all have the same package environement. (In fact, almost
all of the software that we work on here is big enough that we handle it
this way.) It would be inconvenient and error-prone to have to
duplicate the package setup information in each of the files, since it
needs to be modified from time to time. There needs to be some kind of
indirection feature that lets you have one centralized file holding the
package setup. The editor would have to read this centralized file when
the original file is read in.
This leads to problems inherent in storing absolute pathnames inside of
files. On the Lisp Machine, we would store logical pathnames, so that
if the whole group of files were installed at some other site, the
embedded pathname would still work. This is outside the realm of CLTL
as currently defined, but for us it should suffice. There may be other
problems with embedded pathnames that aren't coming to mind, however.
I'd like to hear other comments.
∂19-Apr-85 2133 DLW@SCRC-STONY-BROOK.ARPA "lexical" packages
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 19 Apr 85 21:32:47 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 218506; Sat 20-Apr-85 00:32:28-EST
Date: Sat, 20 Apr 85 00:34 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: "lexical" packages
To: masinter.pa@XEROX.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 17 Apr 85 20:20-EST from masinter.pa@XEROX.ARPA
Message-ID: <850420003442.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
One other thing: you still have to let some of these things work from
interactive Lisp top level, or else it will be hard for programmers to
try things out, learn, interactively debug, and so on. I don't think
in-package is needed, but I think most of the others are.
By the way, our implementation doesn't actually forbid you from typing a
(declare ...) form at top level. It just returns the symbol DECLARE, as
Maclisp did. The interpreter does this with declare forms inside
programs, as well. The compiler gives you a warning, saying that the
declare doesn't belong there, and ignores it.
Your proposal uses the term "special form" in a non-standard way; COND
and DEFUN are special forms. In fact, I think the CLRM is wrong when it
refers to DECLARE as a special form; in fact, (DECLARE ---) isn't a form
at all, the way that the CLRM defines it. This is probably what led to
the ambiguity.
∂21-Apr-85 0357 RAM@CMU-CS-C.ARPA Bug in CLM.
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Apr 85 03:57:37 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Sun 21 Apr 85 06:57:44-EST
Date: Sun, 21 Apr 1985 06:57 EST
Message-ID: <RAM.12104891993.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Bug in CLM.
In CLTL, the description of #S on page 357 refers to the
defstruct constructor macro, when there is no such thing. Obviously
what is meant here is a keyword (as opposed to BOA) constructor
function.
The same description also appears to have an erroneous piece of
lisp code. The symbol KEYWORD is passed to intern to indicate that
the symbol is interned in the keyword package. The manual says that
the package argument "must be a package".
Rob
∂22-Apr-85 2230 JLW Bug in CLM?
To: ram@CMU-CS-A.ARPA
CC: common-lisp@SU-AI.ARPA
Regarding the second of your two bugs -- I notice a difference in
terminology in the manual between some functions of chapter 11 and
others. In particular, some functions are documented like 'package-name'
is, namely it specifies that "The argument must be a package". But
others, such as 'intern' for example, lack any such constraint, and
use phrases like "the specified package".
There is such consistency in this choice of phraseology that I take it to
mean that unless there is a clear statement that the argment must be a
package datatype, then it is permissible for it to be anything reasonably
coerceible to a package. In this case, (intern ... 'KEYWORD) is the same
as (intern ... "KEYWORD") and (intern ... (find-package "KEYWORD"))
-- JonL --
∂23-Apr-85 0234 JLW Problems with packages?
To: common-lisp@SU-AI.ARPA
Just to review, do we all agree that
(1) readtables,
(2) packages,
(3) dynamic variables *read-base* and *read-suppress* etc
all form part of a global database affecting the reader syntax, and that it
is a unique featue of Lisp that this database may be modified dynamically
by the user? Perhaps a fourth point ought to be added:
(4) packages do not solve, nor even address, the problem of lexicality.
Too often in the past several years I've seen persons who "come up" with
a solution to the problem of lexical variables by "putting them in
separate packages". It takes a lot of explaining to separate out the
difference between syntax parsing and program semantics; perhaps it is
because Lisp is so lividly dynamic that this confusion is so easy to make.
On the other hand, the spate of conjectures as to what "lexical packages"
might possibly mean leads to a situation, a variant of (4), which could be
stated as:
(5) lexicality does not solve, nor even address, the problem of packages.
Given this background, and the fact that the "lexical packages" discussion
seems to have been started by a misunderstanding of "lexical" or "packages"
or both, then I think we can best spend our broadcasted mail time focusing
on questions like the following:
(A) What else besides the default setting of *package* should be added
to the set of conventions? is the ZetaLisp "Syntax:" command adequate?
Of course there is *read-base*, but what else?
(B) Must the editor settle all parsing/syntax related settings before
even "loading" in the file ? or can it wait until a READ operation
is applied to some part of the buffer? a "lazy" parsing.
(C) What are reasonable conventions for scoping a database configuration?
Is a file the appropriate scope? What about streams that arent files?
Regarding (B), one may well ask why a line like
(IN-PACKAGE "FOO")
is any more mysterious to a default-context parser than the line
;;; Package: FOO
Dill seemed to be asking this question in his note last week; one needn't
think that the former line has to be subjected to READ any more than the
latter one. But the more lispy looking line *can* be interpreted by
the simple-minded read-eval-print loaded.
Weinreb seemed to summarize the differences between th ZetaLisp approach
and the SpiceLisp approach as the amount of importance attached to the
editor context problem. I hope it will never be the case, such as it
is now in Interlisp, that one can create files which the standard system
tools cannot parse well enough to be able to edit (and, hence to fix
the silly little bug that managed to creep into them). Admittedly it
doesn't happen often, but on those ocasions one must abandon the standard
program/file editor (in Interlisp) and drop down to some kind of text
editor to repair the damage. [It is not, repeat not, such a simple
thing to do to an Interlisp program file, for generally lots of low-level
things you never really wanted to know about will break when you "hand-
edit" a file, and you'll spend half an hour to half a day trying to
figure out random messages about "file maps" and so on.]
-- JonL --
∂24-Apr-85 0655 greek@DEC-HUDSON Code Generated by Macros
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 06:54:42 PST
Date: Wed, 24 Apr 85 09:54:41 EST
From: greek@DEC-HUDSON
Subject: Code Generated by Macros
To: common-lisp@su-ai
Did anyone out there write any of the Common LISP macro definitions
so that they generate DO, DOTIME, DOLIST or the like? Oops.
If the programmer uses a macro inside a construct that establishes
a block named NIL, and then does a RETURN from inside the macro,
there had better not be any blocks named NIL generated by the macro,
or the RETURN will return to the wrong place.
Not an obvious problem, and we blew it. Or maybe the idea of a block
named NIL is bogus.
- Paul
∂24-Apr-85 0714 RAM@CMU-CS-C.ARPA Bug in CLM?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 07:14:05 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 24 Apr 85 10:14:03-EST
Date: Wed, 24 Apr 1985 10:13 EST
Message-ID: <RAM.12105714157.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Jon White <JLW@SU-AI.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Bug in CLM?
In-reply-to: Msg of 23 Apr 1985 01:30-EST from Jon White <JLW at SU-AI.ARPA>
Date: Tuesday, 23 April 1985 01:30-EST
From: Jon White <JLW at SU-AI.ARPA>
cc: common-lisp at SU-AI.ARPA
Re: Bug in CLM?
There is such consistency in this choice of phraseology that I take it to
mean that unless there is a clear statement that the argment must be a
package datatype, then it is permissible for it to be anything reasonably
coerceible to a package. In this case, (intern ... 'KEYWORD) is the same
as (intern ... "KEYWORD") and (intern ... (find-package "KEYWORD"))
Does everyone agree that this is correct? If this is the case, then
may *package* be random things also? Currently Spice Lisp requires
every package argument to be a package.
Rob
∂24-Apr-85 0750 FAHLMAN@CMU-CS-C.ARPA Bug in CLM?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 07:50:03 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 24 Apr 85 10:50:09-EST
Date: Wed, 24 Apr 1985 10:49 EST
Message-ID: <FAHLMAN.12105720714.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Cc: common-lisp@SU-AI.ARPA, Jon White <JLW@SU-AI.ARPA>
Subject: Bug in CLM?
In-reply-to: Msg of 24 Apr 1985 10:13-EST from Rob MacLachlan <RAM>
I seem to have misplaced JONL's original message, so I'm not sure what
"consistency of terminology" he is referring to. I think that any
consistency in the manual is purely coincidental. :-}
I believe that in writing the package chapter we were careful to say
that an argument could be "a package or package name" where that is what
we meant. (A package name can be either a string or a symbol.) When we
don't say that, as in INTERN, "package" means an object of type package
and nothing else. It certainly is not the case that *package* can be
anything but a true package. See page 174, the first sentence after the
heading for section 11.3, for a definitive statement of this.
-- Scott
∂24-Apr-85 0836 WHOLEY@CMU-CS-C.ARPA Code Generated by Macros
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 08:36:03 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Wed 24 Apr 85 11:35:57-EST
Date: Wed, 24 Apr 1985 11:35 EST
Message-ID: <WHOLEY.12105729067.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: greek@DEC-HUDSON.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Code Generated by Macros
In-reply-to: Msg of 24 Apr 1985 09:54-EST from greek at DEC-HUDSON
Yeah, I went through a little bit of contortion to make Do-All-Symbols and
friends be efficient and maintain the right block structure. I don't remember
any other macros in the language that require bending over backwards to do this
sort of thing. Do you have a list of such things that you ran into for the
rest of us?
Zetalisp has some stuff to get around this problem (which makes it easier for
users to write iteration macros that do the right thing), but I doubt it could
be easily added to the Common Lisp language. Since Common Lisp programs are
supposed to be easily machine-analyzable, one might write a portable thing that
mangles the Returns inside a piece of code to return to a block of one's
choice.
It might be worth a sentence or two in the manual to point out to implementors
and users alike that one may have to resort to writing hairy Progs to retain
the "returnability" feature. Implementors are, of course, required to do so
for things specified in CLTL, and users should be encouraged to do so.
--Skef
∂24-Apr-85 0958 greek@DEC-HUDSON Code Generated by Macros
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 09:58:21 PST
Date: Wed, 24 Apr 85 12:58:16 EST
From: greek@DEC-HUDSON
Subject: Code Generated by Macros
To: common-lisp@su-ai
We found that the following "macros" generated loops that hid a
surrounding NIL block:
CCASE
CTYPECASE
DO-SYMBOLS et al
lots of compiler transformations (e.g., that turned a map
into a loop)
Also, of course, plenty of macros written by users can inadvertently
cause the problem.
The simplest way around is to only generate TAGBODYs. Even PROG
establishes a NIL block.
- Paul
∂24-Apr-85 1208 DCP@STONY-BROOK.SCRC.Symbolics.COM Code Generated by Macros
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 12:07:28 PST
Received: from NEPONSET.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223090; Wed 24-Apr-85 15:07:14-EST
Date: Wed, 24 Apr 85 15:07 EST
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Code Generated by Macros
To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 24 Apr 85 09:54-EST from greek at DEC-HUDSON
References: The message of 24 Apr 85 09:54-EST from greek at DEC-HUDSON,
<WHOLEY.12105729067.BABYL@CMU-CS-C.ARPA>
Message-ID: <850424150703.5.NFEP@NEPONSET.SCRC.Symbolics.COM>
Date: Wed, 24 Apr 85 09:54:41 EST
From: greek@DEC-HUDSON
Did anyone out there write any of the Common LISP macro definitions
so that they generate DO, DOTIME, DOLIST or the like? Oops.
If the programmer uses a macro inside a construct that establishes
a block named NIL, and then does a RETURN from inside the macro,
there had better not be any blocks named NIL generated by the macro,
or the RETURN will return to the wrong place.
Not an obvious problem, and we blew it. Or maybe the idea of a block
named NIL is bogus.
I know what you are talking about, but I can't come up with an example
that can't be programmed around. For example,
(defmacro dotimes-named (name (var form) &body body)
`(block ,name
(return-from nil
(block do-return-from-nil
(return-from ,name
(dotimes (,var ,form)
(block dont-return-from-nil
(return-from do-return-from-nil
(block nil
,@body
(return-from dont-return-from-nil))))))))))
It isn't pretty, but it does work. I don't know if there are easier ways
to do this particular things. I have seen easier ways to other similar
things.
Perhaps it is for reasons like this that Lisp Machine Lisp has DO-NAMED?
That is, perhaps DO-NAMED is the prefered thing to expand into instead
of DO, since it won't accidentally steal the block named NIL?
Another way out is to document your macros as "having an implicit block
named NIL".
∂24-Apr-85 1628 GSB@MIT-MC Code Generated by Macros
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 16:28:38 PST
Date: Wed, 24 Apr 85 19:18:08 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: Code Generated by Macros
To: common-lisp@SU-AI
Message-ID: <[MIT-MC].468518.850424.GSB>
Date: Wed, 24 Apr 85 12:58:16 EST
From: greek@DEC-HUDSON
We found that the following "macros" generated loops that hid a
surrounding NIL block:
CCASE
CTYPECASE
DO-SYMBOLS et al
lots of compiler transformations (e.g., that turned a map
into a loop)
Also, of course, plenty of macros written by users can inadvertently
cause the problem.
The simplest way around is to only generate TAGBODYs. Even PROG
establishes a NIL block.
Oh come on. This is what BLOCK and GENSYM are good for. This is why
named PROGs have been useful in the past (in NIL and Zetalisp).
GENSYM is also good for generating tags within your tagbody -- you
still need to worry about uniqueness there.
∂24-Apr-85 1750 Moon@STONY-BROOK.SCRC.Symbolics.COM When is a package name equivalent to a package?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 17:50:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223474; Wed 24-Apr-85 20:49:47-EST
Date: Wed, 24 Apr 85 20:50 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: When is a package name equivalent to a package?
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
cc: Jon White <JLW@SU-AI.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12105714157.BABYL@CMU-CS-C.ARPA>
Message-ID: <850424205010.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 24 Apr 1985 10:13 EST
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Date: Tuesday, 23 April 1985 01:30-EST
From: Jon White <JLW at SU-AI.ARPA>
There is such consistency in this choice of phraseology that I take it to
mean that unless there is a clear statement that the argment must be a
package datatype, then it is permissible for it to be anything reasonably
coerceible to a package. In this case, (intern ... 'KEYWORD) is the same
as (intern ... "KEYWORD") and (intern ... (find-package "KEYWORD"))
Does everyone agree that this is correct? If this is the case, then
may *package* be random things also? Currently Spice Lisp requires
every package argument to be a package.
I think the manual is quite clear.
p.183 requires that the value of *package* be a package.
p.182 specifies that certain functions, including INTERN, shall accept strings
and symbols in place of packages. As is unfortunately typical of the CLM,
this specification is not repeated in the documentation of each of the affected
functions, so it's quite easy to overlook.
∂24-Apr-85 1822 KMP@STONY-BROOK.SCRC.Symbolics.COM When is a package name equivalent to a package?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 18:21:54 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223510; Wed 24-Apr-85 21:21:31-EST
Date: Wed, 24 Apr 85 21:21 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: When is a package name equivalent to a package?
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, RAM@CMU-CS-C.ARPA
cc: JLW@SU-AI.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <850424205010.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <850424212146.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Return-path: <@MIT-MC.ARPA,@SU-AI.ARPA:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from MIT-MC.ARPA by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 223502; 24 Apr 85 21:10:54-EST
Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 APR 85 21:00:04 EST
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 17:50:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223474; Wed 24-Apr-85 20:49:47-EST
Date: Wed, 24 Apr 85 20:50 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: When is a package name equivalent to a package?
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
cc: Jon White <JLW@SU-AI.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12105714157.BABYL@CMU-CS-C.ARPA>
Message-ID: <850424205010.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 24 Apr 1985 10:13 EST
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Date: Tuesday, 23 April 1985 01:30-EST
From: Jon White <JLW at SU-AI.ARPA>
There is such consistency in this choice of phraseology that I take it to
mean that unless there is a clear statement that the argment must be a
package datatype, then it is permissible for it to be anything reasonably
coerceible to a package. In this case, (intern ... 'KEYWORD) is the same
as (intern ... "KEYWORD") and (intern ... (find-package "KEYWORD"))
Does everyone agree that this is correct? If this is the case, then
may *package* be random things also? Currently Spice Lisp requires
every package argument to be a package.
I think the manual is quite clear.
p.183 requires that the value of *package* be a package.
p.182 specifies that certain functions, including INTERN, shall accept strings
and symbols in place of packages. As is unfortunately typical of the CLM,
this specification is not repeated in the documentation of each of the affected
functions, so it's quite easy to overlook.
I wonder if it wouldn't be worth introducing a PACKAGE-BIND special form, as in:
(DEFMACRO PACKAGE-BIND (PACKAGE &BODY FORMS)
`(LET ((*PACKAGE* (FIND-PACKAGE ,PACKAGE))) ,@FORMS))
just so users would never need to explicitly call FIND-PACKAGE.
Sure enough, I just checked and there's an SI:PKG-BIND special form which does
exactly that on the LispM so someone must have agreed with this suggestion...
∂24-Apr-85 1829 Moon@STONY-BROOK.SCRC.Symbolics.COM Code Generated by Macros
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 18:29:19 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223514; Wed 24-Apr-85 21:29:10-EST
Date: Wed, 24 Apr 85 21:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Code Generated by Macros
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 24 Apr 85 12:58-EST from greek@DEC-HUDSON
Message-ID: <850424212930.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 24 Apr 85 12:58:16 EST
From: greek@DEC-HUDSON
We found that the following "macros" generated loops that hid a
surrounding NIL block:
CCASE
CTYPECASE
DO-SYMBOLS et al
lots of compiler transformations (e.g., that turned a map
into a loop)
DO-SYMBOLS is clearly documented to create a block named NIL.
You're right that the others are errors. Our implementation handles
these correctly, but perhaps you were talking about macro definitions in
some other implementation, such as Spice Lisp. It's quite easy to do
them right.
Also, of course, plenty of macros written by users can inadvertently
cause the problem.
The simplest way around is to only generate TAGBODYs. Even PROG
establishes a NIL block.
A good rule of thumb is never to use PROG under any circumstances for
anything.
The real problem is DO, which you would often like to use, but have
to be careful about whether you intended to create a block or not.
A good rule of thumb is to write macros whose name does not start
with "DO" in terms of BLOCK, LET, and TAGBODY only -- then everything
is explicit.
∂24-Apr-85 1905 FAHLMAN@CMU-CS-C.ARPA When is a package name equivalent to a package?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 19:04:28 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 24 Apr 85 22:04:42-EST
Date: Wed, 24 Apr 1985 22:04 EST
Message-ID: <FAHLMAN.12105843536.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <moon%scrc@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: When is a package name equivalent to a package?
In-reply-to: Msg of 24 Apr 1985 20:50-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I think the manual is quite clear.
p.183 requires that the value of *package* be a package.
p.182 specifies that certain functions, including INTERN, shall accept strings
and symbols in place of packages. As is unfortunately typical of the CLM,
this specification is not repeated in the documentation of each of the affected
functions, so it's quite easy to overlook.
Are we looking at the same page 182? Where does it say that? In the
last paragraph it says that "Any argument described as a PACKAGE NAME
may be either a string or a symbol." Is that waht you're thinking of?
Intern takes a package argument, but says nothing about taking a package
name instead.
-- Scott
∂24-Apr-85 1932 Moon@STONY-BROOK.SCRC.Symbolics.COM When is a package name equivalent to a package?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 19:32:38 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223559; Wed 24-Apr-85 22:32:34-EST
Date: Wed, 24 Apr 85 22:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: When is a package name equivalent to a package?
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12105843536.BABYL@CMU-CS-C.ARPA>
Message-ID: <850424223253.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 24 Apr 1985 22:04 EST
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
From: Moon
I think the manual is quite clear.
p.183 requires that the value of *package* be a package.
p.182 specifies that certain functions, including INTERN, shall accept strings
and symbols in place of packages. As is unfortunately typical of the CLM,
this specification is not repeated in the documentation of each of the affected
functions, so it's quite easy to overlook.
Are we looking at the same page 182? Where does it say that? In the
last paragraph it says that "Any argument described as a PACKAGE NAME
may be either a string or a symbol." Is that waht you're thinking of?
Intern takes a package argument, but says nothing about taking a package
name instead.
You're absolutely right. I didn't read the manual carefully enough and missed
the word "name" after "package", especially since two sentences earlier in the
same paragraoh it was talking about arguments named @I[package]. The wording
could use some improvement here, I think.
In fact page 182, now that I am reading it carefully, says nothing about
what values are legal to pass to an argument named package.
Now I have to ask if there is any significance to the fact that the argument
to FIND-PACKAGE is called name rather than package-name.
Obviously I should withdraw the first sentence of my earlier message!
Our implementation of these functions (INTERN, USE-PACKAGE, IMPORT, etc.)
accepts a package name as an argument where a package is required. It seems
natural, and doesn't cost anything if you were doing error-checking anyway (and
blithely assuming that the argument is a package seems extra-dangerous here!).
However, I won't advocate that every implementation be required to accept a
package name in place of a package.
∂24-Apr-85 2057 Moon@STONY-BROOK.SCRC.Symbolics.COM Problems with packages?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 20:57:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223602; Wed 24-Apr-85 23:56:50-EST
Date: Wed, 24 Apr 85 23:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Problems with packages?
To: Jon White <JLW@SU-AI.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 23 Apr 85 05:34-EST from Jon White <JLW@SU-AI.ARPA>
Message-ID: <850424235711.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 23 Apr 85 0234 PST
From: Jon White <JLW@SU-AI.ARPA>
....I think we can best spend our broadcasted mail time focusing
on questions like the following:
(A) What else besides the default setting of *package* should be added
to the set of conventions? is the ZetaLisp "Syntax:" command adequate?
Of course there is *read-base*, but what else?
(B) Must the editor settle all parsing/syntax related settings before
even "loading" in the file ? or can it wait until a READ operation
is applied to some part of the buffer? a "lazy" parsing.
(C) What are reasonable conventions for scoping a database configuration?
Is a file the appropriate scope? What about streams that arent files?
(B): In our editor, "loading" in a file applies READ operations to parts of it.
How else is it supposed to know what functions are defined in the file?
The READ operation used is of course parameterized by the language and dialect
the file is written in, along with language-dependent parameters such as the
package.
Regarding (B), one may well ask why a line like
(IN-PACKAGE "FOO")
is any more mysterious to a default-context parser than the line
;;; Package: FOO
I explained earlier that some editors, such as ours, need to support
multiple languages. Not all languages have the same syntax for
statements in the language itself (clearly!), but every language that
we've heard of has comments and the same syntax of file attribute line
(the line with the -*-) can be used inside the comments of every
language that we've heard of.
To give a concrete example of the issues: of the three dialects of Lisp
we support, only one contains a function named IN-PACKAGE.
Dill seemed to be asking this question in his note last week; one needn't
think that the former line has to be subjected to READ any more than the
latter one. But the more lispy looking line *can* be interpreted by
the simple-minded read-eval-print loaded.
It would be possible to make an editor that understands package
specifications in some clearly defined syntax besides the clearly
defined syntax of the file attribute line, and looks for that syntax if
it doesn't find a file attribute line. Common Lisp does not begin to
specify such a syntax, it merely suggests (p.182) that "all of the
package setup forms appear near the start of the file." I'm not
interested in spending my limited energies making this specification
concrete enough that it could be useful to a program, but perhaps others
are.
∂25-Apr-85 0054 JLW When is a package name equivalent to a package?
To: fahlman@CMU-CS-C.ARPA, moon@SCRC-STONY-BROOK.ARPA
CC: common-lisp@SU-AI.ARPA
In-reply-to: your messge of 24-Apr-85 22:04 EST
There are only three places I can remember that explicitly say
"... must be a package": the definition of *package*, the argument to
package-name, and the argment to package-nicknames. It would seem reasonable
to me to let all other arguments called "package" be coercible from symbols,
strings, and packages. I can't say that requireing the arguments to
package-name and package-nicknames to be "a package" achieves anything;
I'd be happier with Moon's suggestion to let all function args be coercible.
Actually, another constraint has been bugging me recently -- the argument
to in-package is constrained to be a "name"; why not let it be a package
also? If you did so, it would have no bearing one way or other on the
advisibility of using a form like
(IN-PACKAGE "USER")
as a CL minor-mode specifier.
∂25-Apr-85 0343 JLW More on (B): the editor's "reading" of files
To: moon@SCRC-STONY-BROOK.ARPA
CC: common-lisp@SU-AI.ARPA
In-reply-to: your message of 24-Apr-85 23:57 EST
OK, I buy the argument that the editor wants to be able to distinguish
various language types [egad, some even do so by looking at the "extension"
field of the file name]; but after having made that distinction, wouldn't
it be reasonable to dispatch off to a programmable attribute-parser that
could be quite different from one language to another?
That is, given that you know that a file is in Common Lisp syntax (as
opposed to, say, Franz, or Fortran, or random text), then some flavor
of specialized parser would rip along and find out attributes that are
possibly unique to common lisp and possibly shared with other lisps.
One of the problems with the ;;; -*- convention is its lack of
"tailor-ability" by the user; and as this whole line of discussions has
brought out, there are more and more things that seem to want to be
in the attributes lines.
Of course, these are only conventions for the initial, or default, settings
of various user-accessible switches on the READer -- as DLW pointed out,
one may still have to process the file "in order", form by form, to be
100% sure of the correct state at any paticular point in the file. Yet,
if some convention like this isn't adopted, then will CL be substandard
compared to zetalisp or spicelisp? One of the latter two conventions
could be adopted bodily into CL; I'm sure you have a preference here.
Interlisp has a number of internal, non-READ parsers that inspect the first
portion of a file for certain information. But it is mainly a time-saving
hack that READ isn't used, because such source files are virtually always
mechaniclly produced, and have a very rigid format; in Interlisp, you
can *always* READ the first expression or so of the file and look at it
with CAR and CDR etc, because the Interlisp reader has no errors other
than premature end of file. [well, almost *no* errors -- there is the
problem that symbols are limited to 256 characters. I fixed a bug related
to this limitation sometime last year.]
By the bye, I'm not sure if your reply laid to rest my "fear" that one
can produce an almost-correct common lisp source file which the zetalisp
editor can't even bring in to a buffer (previous note used "load") because
it dies trying to READ some little part of it that happens to be total
garbage. What's the scoop?
-- JonL --
∂25-Apr-85 0419 JLW What package are feature names resident in?
To: common-lisp@SU-AI.ARPA
Bottom of page 358 clearly suggests that #+ should READ in the expression
following the +, and obtain symbols which are tested for MEMBERship in
the *features* list. So what should happen from the following fragment:
(in-package "LUSER")
(push 'dull *features*)
(in-package "WINNER")
(push 'snazzy *features*)
(in-package "USER")
'(a #+dull b #+snazzy c )
Now, how long a list is the last form read?
Consider when package LUSER is, and is not, a user of package LISP; and
when "dull" is, and is not, an external symbol of the LISP package.
I believe I see two schools of thought, exemplified in the several
implemetations I've looked at so far. One says that feature names can be
any lisp objects, and since luser:snazzy and winner:snazzy are two separate
features, you have to be careful about which one you really mean. The
other school says that feature names are analogous to the names of
packages -- a kind of global namespace -- and will probably implement #+
by binding *package* to some canonical place (like, the keyword package).
I'm not sure I can give an adequate defense of either position, but
the fact that two different implementations initialize their *features*
lists to symbols in different packages makes it difficult to interpret
forms like
#+Lispm (do-this)
because you don't which symbol the "Lispm" will turn into. Should you
have to say
#+:Lispm (do-this)
I don't think this was intended (to have to put package qualifiers for
feature names), but if there are two differing implemetations . . .
Some folks here at Lucid think there was discussion on the matter a couple
years ago, but no one seems sure if a resolution was achieved. Any
commets?
-- JonL --
P.S. The problem isnt IN-PACKAGE -- as someone pointed out already, it
is so trivial as to be almost redundant. Most usages of it would be
equivalent to (setq *package* (find-package <package-name>)).
∂25-Apr-85 0642 greek@DEC-HUDSON Code Generated by Macros
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 25 Apr 85 06:42:05 PST
Date: Thu, 25 Apr 85 09:42:03 EST
From: greek@DEC-HUDSON
Subject: Code Generated by Macros
To: common-lisp@su-ai
Dave Plummer - Yes, I understand that you can write named DOs, and that
Common LISP should probably have one (and maybe not the DO we actually
have). I was simply pointing out that standard Common LISP macros
could potentially be written incorrectly. That macro you supplied,
DOTIMES-NAMED, doesn't seem to work.
Glenn Burke - Huh? I'm not at all sure what you are trying to say.
PROG is, in fact, no good for this problem since it generates a NIL
block.
Dave Moon - Thank you for that succinct summary. In fact, we DID
have a problem with DO-ALL-SYMBOLS, because it used DO-SYMBOLS, so
that two NIL blocks were generated and a RETURN would not quite get
all the way out. That's what I was trying to say.
- Paul
∂25-Apr-85 1507 Moon@STONY-BROOK.SCRC.Symbolics.COM More on (B): the editor's "reading" of files
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 25 Apr 85 15:06:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 224275; Thu 25-Apr-85 18:06:30-EST
Date: Thu, 25 Apr 85 18:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: More on (B): the editor's "reading" of files
To: Jon White <JLW@SU-AI.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 25 Apr 85 06:43-EST from Jon White <JLW@SU-AI.ARPA>
Message-ID: <850425180639.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 25 Apr 85 0343 PST
From: Jon White <JLW@SU-AI.ARPA>
....By the bye, I'm not sure if your reply laid to rest my "fear" that one
can produce an almost-correct common lisp source file which the zetalisp
editor can't even bring in to a buffer (previous note used "load") because
it dies trying to READ some little part of it that happens to be total
garbage. What's the scoop?
We provide and document a command that reads a file into the editor without
looking at its attributes. You are then editing the file in Fundamental Mode,
and the editor makes no attempt to do anything language-specific.
∂25-Apr-85 1523 fateman%ucbdali@Berkeley RPG's benchmarks coming out as an MIT press book
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 25 Apr 85 15:23:19 PST
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.46)
id AA05204; Thu, 25 Apr 85 15:22:11 pst
Received: by ucbdali.ARPA (4.24/4.46)
id AA13833; Thu, 25 Apr 85 15:23:59 pst
Date: Thu, 25 Apr 85 15:23:59 pst
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8504252323.AA13833@ucbdali.ARPA>
To: rpg@su-ai
Subject: RPG's benchmarks coming out as an MIT press book
Cc: common-lisp@su-ai
If the benchmarks which I submitted are going to appear in a copyrighted
book, I would like explicit permission
to appear that says that reproduction of the code, and reprinting of the
tables with additional data, and similar modifications or corrections
can be done without copyright hassles.
If it appears that I will lose control of programs that I wrote
as a consequence of RPG's paper, I would prefer to withdraw my benchmark.
Although I think that an MIT press copyright of such a program would be invalid,
let's try to set the correct precedent this time. We messed up
royally on CLTL and Digital Press, in my opinion.
∂25-Apr-85 1935 FAHLMAN@CMU-CS-C.ARPA When is a package name equivalent to a package?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 25 Apr 85 19:35:11 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 25 Apr 85 22:35:31-EST
Date: Thu, 25 Apr 1985 22:35 EST
Message-ID: <FAHLMAN.12106111284.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Jon White <JLW@SU-AI.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: When is a package name equivalent to a package?
In-reply-to: Msg of 25 Apr 1985 03:54-EST from Jon White <JLW at SU-AI.ARPA>
In the earlier messages we were discussing what the current situation
is, according to the manual. I don't have time to search the archives,
but it seems to me that where we said "package", we meant "package". We
might even have had a good reason for this.
If we are going to discuss changes, right now it sounds reasonable to me
to allow package names in most of the places that are documented to take
packages -- all except *package*, package-name, and package-nicknames --
as you suggest. I can't construct a good argument against this right
now.
-- Scott
∂26-Apr-85 1211 RAM@CMU-CS-C.ARPA What package are feature names resident in?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Apr 85 12:11:22 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Fri 26 Apr 85 15:11:22-EST
Date: Fri, 26 Apr 1985 15:11 EST
Message-ID: <RAM.12106292554.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Jon White <JLW@SU-AI.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: What package are feature names resident in?
In-reply-to: Msg of 25 Apr 1985 07:19-EST from Jon White <JLW at SU-AI.ARPA>
I believe that the issue discussed was "Should features always be
keywords?" The conclusion was "No, but they can be." An implication
of this decision is that features are packaged symbols.
Rob
∂26-Apr-85 1453 GSB@MIT-MC package names, consistency
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Apr 85 14:52:38 PST
Date: Fri, 26 Apr 85 17:47:24 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: package names, consistency
To: common-lisp@SU-AI
Message-ID: <[MIT-MC].471684.850426.GSB>
Date: Thu, 25 Apr 1985 22:35 EST
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
. . .
If we are going to discuss changes, right now it sounds reasonable to me
to allow package names in most of the places that are documented to take
packages -- all except *package*, package-name, and package-nicknames --
as you suggest. I can't construct a good argument against this right
now.
This sounds reasonable. If one wants to draw comparisons, however, the
various PATHNAME "accessors", such as pathname-host, pathname-name, all
take anything which can be coerced to a pathname...
There are a few other things, mostly nomenclature inconsistencies,
which i have found myself explaining more than once. One of the worst
appears to be simple-vector. It should have been left as
simple-general-vector in spite of the verbiage.
∂27-Apr-85 1142 TIM@MIT-MC Editing multiple package files
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Apr 85 11:42:32 PST
Date: Sat, 27 Apr 85 14:42:44 EST
From: Tim McNerney <TIM@MIT-MC>
Subject: Editing multiple package files
To: DLW@SCRC-STONY-BROOK
cc: Common-Lisp@SU-AI
Message-ID: <[MIT-MC].472449.850427.TIM>
Date: Thu, 18 Apr 85 13:10 EST
From: Daniel L. Weinreb <DLW at TENEX.SCRC.Symbolics.COM>
To: TIM at MC.MIT
cc: common-lisp at SU-AI.ARPA
Re: Compilation and package system, an addendum
Date: Thu,18 Apr 85 01:22:26 EST
From: Tim McNerney <TIM@MIT-MC>
Yes, there could be an arbitrary amount of hair, but there is a big
difference between assuming that an entire file will be read in the
package declared by the -*- line and supporting lusers who want to
generate the screw cases you allude to above. Once the package
environment is established, simply having the ZMACS keep a package
attribute for each section will support editing files like patch files
which need to be read in a number of different packages.
You seem to be saying that the high cost can be avoided by not
supporting "lusers" who generate the "screw cases". In other words, the
editor should not actually parse the entire file, because that costs too
much, and it's OK if it does the wrong thing for the screw cases. I
could be convinced of that principle. So, what is your counterproposal?
Exactly what will the editor do when a file is read in, such that it
does all the right things except in "screw cases"? How does it know
where to stop parsing?
And if you expect the editor to work correctly on files like patch
files, with different package environments in each section, then you
certainly do need to scan the entire file. If you disagree, what's
your countersuggestion?
No, not at all. You seem to have misunderstood me completely (This
probably stems from your not having read the message that my message
(above) was an addendum to).
The original message merely suggested that since the editor has to
scan the file at least once, namely when the file is first being read
into the buffer (during "sectionization" in Zmacs' case), that the
editor record the package for each definition at that time. The
"screw cases" that I refer to are those where a NON-TRIVIAL package
environment is set up BY THE FILE BEING READ IN. As I said, once the
package environment is stable, having the editor support multiple
package files is more tractable.
∂28-Apr-85 1123 RPG Common Lisp song considered offensive?
∂27-Apr-85 1217 WHOLEY@CMU-CS-C.ARPA Common Lisp song considered offensive?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Apr 85 12:17:38 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Sat 27 Apr 85 15:17:50-EST
Date: Sat, 27 Apr 1985 15:17 EST
Message-ID: <WHOLEY.12106555872.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Fahlman@CMU-CS-C.ARPA, Steele@THINK.ARPA, Moon@SCRC-STONY-BROOK.ARPA,
DLW@SCRC-STONY-BROOK.ARPA, RPG@SU-AI.ARPA
Subject: Common Lisp song considered offensive?
Yesterday I received a piece of air mail from Taiichi Yuasa of Kyoto
University. He and M. Hagiya are writing an article about "the current
movement of Common Lisp people in the States." While looking through the
archives of the Common Lisp mailing list, they found my Common Lisp song, sung
to the tune of Bob Dylan's "Maggie's Farm." They wrote asking me permission to
include it in their article. I mentioned this to Scott, and he pointed out
that the song may be considered offensive to those of you mentioned in it.
If any of you object, I'll write to these guys and tell them not to print it.
To refresh your memories, the song implies (verse for verse) that
1. Common Lisp is a compromise -- it's less than perfect,
2. Fahlman runs a sweat shop,
3. Steele doesn't read his mail,
4. Moon is responsible for great gobs of hair, including Defsetf, and
the Gang of Five settled some issues without the consent of the rest of
those on the Common Lisp mailing list, and
6. Some Lispers raised on pre-modern Lisps can't appreciate the fact that
Explode and friends are gone.
I didn't think these things are particularly nasty, but understand that some of
you might not appreciate these things being published in Japanese BIT, "one of
the most popular computer science journals in Japan." Let me know if that's
the case.
--Skef
∂28-Apr-85 1124 RPG Common Lisp song considered offensive?
∂27-Apr-85 1824 FAHLMAN@CMU-CS-C.ARPA Common Lisp song considered offensive?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Apr 85 18:23:53 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 27 Apr 85 21:23:38-EST
Date: Sat, 27 Apr 1985 21:23 EST
Message-ID: <FAHLMAN.12106622464.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Skef Wholey <Wholey@CMU-CS-C.ARPA>
Cc: DLW@SCRC-STONY-BROOK.ARPA, Moon@SCRC-STONY-BROOK.ARPA, RPG@SU-AI.ARPA,
Steele@THINK.ARPA
Subject: Common Lisp song considered offensive?
In-reply-to: Msg of 27 Apr 1985 15:17-EST from Skef Wholey <Wholey>
I don't think that people not closely involved in this effort will have
any idea what most of the song is about, especially if they're Japanese.
I'm not sure they'll even know what a Perq is, let alone an X-1 key.
But I have no desire to stifle free speech, and it is undeniable that I
run a sweatshop. (The Perq flashes a subliminal message with sexual
overtones that keeps my undergrads coming back for more -- a technique I
learned during my days as a brain programmer for the Illuminati.) So I
won't be the one to object. This article couldn't do nearly as much
damage as the Gabriel and Brooks "critique" or the upcoming publication
of last year's Lisp benchmarks by MIT Press.
-- Scott
∂28-Apr-85 1124 RPG Common Lisp song considered offensive?
∂27-Apr-85 2101 DLW@QUABBIN.SCRC.Symbolics.COM Common Lisp song considered offensive?
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 27 Apr 85 21:01:32 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 158141; Sat 27-Apr-85 23:59:49-EST
Date: Sun, 28 Apr 85 00:04 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Common Lisp song considered offensive?
To: Wholey@CMU-CS-C.ARPA, Fahlman@CMU-CS-C.ARPA, Steele@THINK.ARPA,
Moon@STONY-BROOK.SCRC.Symbolics.COM, RPG@SU-AI.ARPA
cc: cwh@TENEX.SCRC.Symbolics.COM
In-Reply-To: <WHOLEY.12106555872.BABYL@CMU-CS-C.ARPA>
Message-ID: <850428000401.8.DLW@CHICOPEE.SCRC.Symbolics.COM>
I wish you had been here to hear my side-splitting laughter when I read
your message. From my (admittedly limited) experience, this is a very
characteristically Japanese request. Yuasa probably considers this a
great hack, and BIT would certainly publish it. Anyway, it's fine with
me. You might, however, want to ask him to run the idea by Masayuki
Ida, who is trying to get Common Lisp adopted as an industry standard of
JIEDA (sp?), and who is translating the manual into Japanese, just to
see if he'd consider it a problem. It's fine with me, personally (I
don't even think I'm mentioned, anyway).
∂28-Apr-85 1400 Moon@SCRC-STONY-BROOK.ARPA Any complete CL implementations??
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Apr 85 13:59:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 225397; Sun 28-Apr-85 16:59:17-EDT
Date: Sun, 28 Apr 85 17:00 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Any complete CL implementations??
To: Rem%IMSSS@SU-SCORE.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 5 Apr 85 15:24-EST from Rem@IMSSS
Message-ID: <850428170009.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 5 Apr 1985 1224-PST
From: Rem@IMSSS
At this time, has anybody completely 100% implemented Common LISP
on any machine at all? ....
I guess no one at Symbolics has answered this. Our implementation of
Common Lisp, included in Release 6.0 of our 3600 software, is intended to
be complete and correct. I'm sure there are still bugs that have not yet
been found and fixed. In addition, there is a brief list of known deviations
from the standard, which can be found in volume 2 of the Release 6 documentation
set. The functions and features that are not implemented, according
to that list, are integers as GO tags, certain declarations, row-major-order
arrays, ARRAY-ROW-MAJOR-INDEX, MAKE-CONCATENATED-STREAM, MAKE-ECHO-STREAM,
and ~E and ~G in FORMAT. The other deviations are minor: for details, find
a 3600 installation and ask to look at their Release 6 documentation.
∂28-Apr-85 2033 RPG Common Lisp song considered offensive?
∂28-Apr-85 1917 FAHLMAN@CMU-CS-C.ARPA Common Lisp song considered offensive?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 28 Apr 85 19:16:57 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 28 Apr 85 22:16:40-EDT
Date: Sun, 28 Apr 1985 22:16 EDT
Message-ID: <FAHLMAN.12106883352.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: DLW@SCRC-STONY-BROOK.ARPA, RPG@SU-AI.ARPA, Steele@THINK.ARPA,
Skef Wholey <Wholey@CMU-CS-C.ARPA>
Subject: Common Lisp song considered offensive?
In-reply-to: Msg of 28 Apr 1985 16:33-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Actually if I remember correctly I'm not responsible for DEFSETF,
only for cleaning it up and simplifying it, but I didn't check any
archives.
I remember the event fairly well. DEFSETF was simple but buggy on a few
things such as LDB. You were the one who pointed this out and indicated
that in order to do DEFSETF right in the hard cases we had to go with
the five-fold version, DEFINE-SETF-METHOD (which you got from Bawden, I
believe). So while you were not responsible for DEFSETF, you were the
one who brought the ultra-hairy version into the picture. I guess that
counts as "claening up", but I'm not so sure about "simplifying".
Of course, I'd have just swept this particular problem under the rug,
which is why my rugs are always so lumpy. One advantage of having a
group working on this kind of thing is that each of us was inclined to
be lazy about a different set of things, and there was usually someone
around to heap scorn on such laziness.
-- Scott
∂29-Apr-85 1300 Moon@SCRC-VALLECITO.ARPA wimpy COERCE function
Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 29 Apr 85 13:00:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 10269; Mon 29-Apr-85 16:00:33-EDT
Date: Mon, 29 Apr 85 16:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: wimpy COERCE function
To: Niels Lauritzen <SR.LAURITZEN%MIT-SPEECH@MIT-MC.ARPA>
cc: BUG-LISPM%MIT-SPEECH@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: <850428192527.1.LAURITZEN@YOGI.MIT>
Message-ID: <850429160029.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sunday, 28 April 1985, 19:25-EDT
From: Niels Lauritzen <SR.LAURITZEN at MIT-SPEECH>
In Symbolics 3670 Release 6.0
>>Error: I don't know how to coerce an object to an integer modulo 3
Hey, any computer ought to know how to coerce integers to integers modulo N.
COERCE: (P.C. = 22)
Arg 0 (OBJECT): 45
Arg 1 (TO-TYPE): (MOD 3)
I agree that this coercion would be easy to implement, provided you could get everyone
to agree that what you meant was (MOD 45 3) rather than signalling an error that 45
was out of range.
On the other hand, if you read the documentation of COERCE in the Common Lisp manual,
this is not one of the coercions that it lists as permissible.
I'm cc'ing this to the Common-Lisp mailing list in case anyone there wants to discuss
the pros and cons of what Common Lisp specifies for COERCE. That discussion should
not include the other recipients, please.
∂29-Apr-85 1714 RWK@SCRC-STONY-BROOK.ARPA More on (B): the editor's "reading" of files
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 Apr 85 17:13:51 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 226043; Mon 29-Apr-85 20:12:59-EDT
Date: Mon, 29 Apr 85 20:13 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: More on (B): the editor's "reading" of files
To: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
cc: Jon White <JLW@SU-AI.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <850425180639.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <850429201354.0.RWK@CROW.SCRC.Symbolics.COM>
Date: Thu, 25 Apr 85 18:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: 25 Apr 85 0343 PST
From: Jon White <JLW@SU-AI.ARPA>
....By the bye, I'm not sure if your reply laid to rest my "fear" that one
can produce an almost-correct common lisp source file which the zetalisp
editor can't even bring in to a buffer (previous note used "load") because
it dies trying to READ some little part of it that happens to be total
garbage. What's the scoop?
We provide and document a command that reads a file into the editor without
looking at its attributes. You are then editing the file in Fundamental Mode,
and the editor makes no attempt to do anything language-specific.
Also, we make use of our error system to trap such errors,
report the problem gracefully, and then read it in in Fundamental
Mode.
∂30-Apr-85 0735 DLW@SCRC-STONY-BROOK.ARPA wimpy COERCE function
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 30 Apr 85 07:35:18 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 226352; Tue 30-Apr-85 10:34:29-EDT
Date: Tue, 30 Apr 85 10:38 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: wimpy COERCE function
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <850429160029.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <850430103856.8.DLW@CHICOPEE.SCRC.Symbolics.COM>
I'd say it's clear that both the letter and the spirit of the manual say
that this should signal an error. I feel that this is the right thing.
The name MOD appears to be a pun capable of confusing people: it's just
an abbreviation.
∂04-May-85 0838 RAM@CMU-CS-C.ARPA Misfeature: macros expanding into declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 May 85 08:38:27 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Sat 4 May 85 11:08:50-EDT
Date: Sat, 4 May 1985 07:36 EDT
Message-ID: <RAM.12108296011.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Misfeature: macros expanding into declarations
The Common Lisp feature of allowing a macro to expand into
declarations ought to be flushed; it complicates much code while
giving no useful return. I suspect some of the complications were not
forseen when this feature was added to the language. I believe that
the original purpose of this feature is subsumed by Deftype (which was
added later).
The largest issue that I see is that writing macros that parse
declarations becomes much more complicated. Every macro writer must
duplicate the non-trivial code which expands macros looking for
declarations. Even if the macro writer goes to this trouble, a
subtlety that he is sure to miss is supplying the &environment keyword
to defmacro so that he can pass the lexical environment to
macroexpand.
If this feature must remain, then there should be standard
functions for parsing declarations in the language. This might not be
a bad idea anyway, but if the misfeature was eliminated there would be
no need to pass in the lexical environment.
I won't even discuss the hair & inefficiency that this misfeature
adds to the system for fear of being accused of being a wimp or
interpreter weenie; anyone who has implemented a Common Lisp knows it
all too well.
Rob
∂04-May-85 1209 FAHLMAN@CMU-CS-C.ARPA Misfeature: macros expanding into declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 May 85 12:09:13 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 4 May 85 15:09:43-EDT
Date: Sat, 4 May 1985 15:09 EDT
Message-ID: <FAHLMAN.12108378504.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Misfeature: macros expanding into declarations
In-reply-to: Msg of 4 May 1985 07:36-EDT from Rob MacLachlan <RAM>
I agree with Rob: we should eliminate the ability of a macro in certain
places to expand into a declaration. I cannot think of anything
essential that this feature buys us, and it certainly has caused many
bugs and lots of inefficiency in the various interpreters that I've
seen. Code analysis tools would all have similar problems with this.
If I remember the original debate on this, it was a "what the hell, it
might be useful someday, let's add it" sort of decision, whose
consequeces we didn't totally appreciate. If there's some important
case that really needs this feature, that's different, but I don't think
that there is. Nor do I believe that there are more than ten lines of
Common Lisp code anywhere in the world (outside of validation tests)
that depend on this feature, so taking it out at this late date wouldn't
cause major upheavals.
Note that we are not arguing against the ability of a macro to turn into
some top-level form such as a DO that, among other things, contains
declarations. We are arguing for the elimination of the feature
described on page 154, in the paragraph starting "It is permissible..."
-- Scott
∂04-May-85 1529 TIM@MIT-MC Misfeature: macros expanding into declarations
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 May 85 15:29:25 PDT
Date: Sat, 4 May 85 18:26:24 EST
From: Tim McNerney <TIM@MIT-MC>
Subject: Misfeature: macros expanding into declarations
To: Fahlman@CMU-CS-C
cc: TIM@MIT-MC, common-lisp@SU-AI, RAM@CMU-CS-C
In-reply-to: Msg of Sat 4 May 1985 15:09 EDT from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Message-ID: <[MIT-MC].485362.850504.TIM>
Date: Sat, 4 May 1985 07:36 EDT
From: Rob MacLachlan <RAM at CMU-CS-C.ARPA>
The Common Lisp feature of allowing a macro to expand into
declarations ought to be flushed; it complicates much code while
giving no useful return.
Although this "misfeature" makes life much harder on the Lisp implementor and
the macro writer, its semantics are not without utility. Let me illustate
this with a couple of simple examples:
;;; Example 1
(defmacro declare-my-specials ()
'(declare (special *foo* *bar* *baz))
;; Once this is done, you can use this in all the functions which
;; use these special variables like so:
(defun frob1! (a b)
(declare-my-specials)
...)
(defun frob2 (x)
(declare-my-specials)
...)
;;; Example 2
(defmacro declare-inlines ()
(declare (special *debugging-p*))
(if *debugging-p* ;Compile time flag
'(declare (notinline car cdr)
'(declare (inline car cdr eq)))
;; Then this declaration macro can be used is time-critical code like so:
(defun %eq-seconds-p (list-1 list-2)
(declare-inlines)
(eq (cadr list-1) (cadr list-2)))
I am not saying that permitting macros to expand into declarations as stated
on p. 154 is a good mechanism for achieving this effect, but there should be
some way of getting the functionality suggested in the above examples.
From: Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Note that we are not arguing against the ability of a macro to turn into
some top-level form such as a DO that, among other things, contains
declarations. We are arguing for the elimination of the feature
described on page 154, in the paragraph starting "It is permissible..."
I don't think that is reasonable to require the programmer to define macros
like DEFUN-WITH-MY-SPECIALS or DEFUN-WITH-DEBUGGABLE-INLINES or anything of
the sort. At top level, these stand a good chance of confusing editors and
human readers.
For the sake of Lisp implementers and macro writers, I would suggest that
this mechanism be flushed in favor of a user-extensible DECLARE. The DEFTYPE
macro is seriously deficient in this role. Rather than using
(DECLARE-MY-SPECIALS) above, I could use (DECLARE (MY-SPECIALS)) or something
of the sort after defining MY-SPECIALS in some way.
From: Rob MacLachlan <RAM at CMU-CS-C.ARPA>
The largest issue that I see is that writing macros that parse
declarations becomes much more complicated. Every macro writer must
duplicate the non-trivial code which expands macros looking for
declarations.
If this feature must remain, then there should be standard
functions for parsing declarations in the language. This might
not be a bad idea anyway...
This is a great suggestion! This would save a lot of duplicated effort.
Case in point:
;Insert form after any declarations. This is about the fifth place
;in the system that knows how to do this; somebody fix this.
(DEFUN INSERT-INTO-BODY (FORM BODY)
(LOOP WHILE (AND (CDR BODY)
(OR (STRINGP (CAR BODY))
(AND (LISTP (CAR BODY))
(EQ (CAAR BODY) 'DECLARE))))
COLLECT (POP BODY) INTO DECLARATIONS
FINALLY (RETURN (NCONC DECLARATIONS (NCONS FORM) BODY))))
--From sys:sys2;flavor.lisp.564 (c) 1985 Symbolics, Inc.
Of course the common lisp version would be much hairier if the "misfeature"
were allowed to remain.
Tim
∂04-May-85 1543 vanroggen@DEC-HUDSON macr --> declares
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 4 May 85 15:43:01 PDT
Date: Sat, 04 May 85 18:44:06 EDT
From: vanroggen@DEC-HUDSON
Subject: macr --> declares
To: common-lisp@su-ai
Cc: vanroggen
I complained about this a while ago, and at the time, no one seemed to think
it worth changing the language definition. But it is a useful feature, and
not having macros expand into declarations won't avoid having some macros
needing to parse declarations.
While we're into complaining about declarations, I'd like to grouse about
type declarations not being meaningful when not applied to a binding in
the immediate special form or macro. The ability to say that a variable
will always be a certain type within a small body of code is very useful
and very common. Officially, requiring one to write a LET or the like just
so one can write a type declaration is very annoying.
---Walter
∂04-May-85 1549 RAM@CMU-CS-C.ARPA Misfeature: macros expanding into declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 May 85 15:49:30 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Sat 4 May 85 18:49:56-EDT
Date: Sat, 4 May 1985 18:49 EDT
Message-ID: <RAM.12108418593.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Tim McNerney <TIM@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA, Fahlman@CMU-CS-C.ARPA
Subject: Misfeature: macros expanding into declarations
In-reply-to: Msg of 4 May 1985 19:26-EDT from Tim McNerney <TIM at MIT-MC>
I think both of your examples are better handled by other
mechanisms that already exist.
In you (declare (special ...)) example, I suspect that making the
variables globally special would work better. The only time it
wouldn't work was if you were actually binding the variables, and
sometimes bound them specially and sometimes not. I doubt that anyone
does this, and if they do, it should probably be glaringly obvious.
As for the second example, I suggest:
(defun %eq-seconds-p (list-1 list-2)
#-debugging-p
(declare (inline car cdr eq)))
(eq (cadr list-1) (cadr list-2)))
Are these samples of real code, or are they just contrived examples?
Rob
∂04-May-85 1557 RAM@CMU-CS-C.ARPA macr --> declares
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 May 85 15:57:07 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Sat 4 May 85 18:57:23-EDT
Date: Sat, 4 May 1985 18:57 EDT
Message-ID: <RAM.12108419950.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: vanroggen@DEC-HUDSON.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: macr --> declares
In-reply-to: Msg of 4 May 1985 18:44-EDT from vanroggen at DEC-HUDSON
I complained about this a while ago, and at the time, no one seemed to
think it worth changing the language definition. But it is a useful
feature, and not having macros expand into declarations won't avoid
having some macros needing to parse declarations.
It won't eliminate the need for *any* macro's declaration parsing; it
will make it easier to do correctly. I suspect that at the time,
nobody had implemented a macro that parsed declarations correctly, and
it is entirely possibly that this is still the case.
I challenge you assertion that it is a useful feature---show me.
Rob
∂05-May-85 0145 HEDRICK@RUTGERS.ARPA (setf (apply #'foo
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 5 May 85 01:44:54 PDT
Date: 5 May 85 02:59:26 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: (setf (apply #'foo
To: common-lisp@SU-AI.ARPA
According to the manual, (setf (apply #'foo x y) z) is defined only when
(setf (foo x y) z) expands to something of the form (set-foo z x y). In
this case the original SETF expands to (apply #'set-foo z x y). I claim
that this statement is vacuous. The problem is that no SETF form can
expand in this way. To do so would violate the provision that SETF
must preserve left to right evaluation. Certainly left to right
evaluation can be preserved by complex patterns involving LET, etc.
However in the case where SETF expands to a simple function call, it
is clear that the arguments must be in the same order as the arguments
to the original SETF. In that case, the new value must be last, which
violates the preconditions for (SETF (APPLY
-------
∂05-May-85 0853 FAHLMAN@CMU-CS-C.ARPA macr --> declares
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85 08:53:09 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 5 May 85 11:53:10-EDT
Date: Sun, 5 May 1985 11:53 EDT
Message-ID: <FAHLMAN.12108604865.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: vanroggen@DEC-HUDSON.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: macr --> declares
In-reply-to: Msg of 4 May 1985 18:44-EDT from vanroggen at DEC-HUDSON
While we're into complaining about declarations, I'd like to grouse about
type declarations not being meaningful when not applied to a binding in
the immediate special form or macro. The ability to say that a variable
will always be a certain type within a small body of code is very useful
and very common. Officially, requiring one to write a LET or the like just
so one can write a type declaration is very annoying.
It would be even more annoying to find that you've created a nice,
local, lexical variable binding and that its type is being mysteriously
restricted by some declaration off in left field somewhere. I think
that it is clear that we want all of the declarations relevant to a
lexical variable binding to be present right there with the binding.
Of course, a SPECIAL proclamation can have non-local effects on what
would otherwise be lexical bindings, but at least we try to minimize the
bug-creation potential of this by encouraging people to use the *foo*
convention for such globally-special variables.
What does seem to be reasonable is to allow pervasive type declarations
for global special variables. It seems reasonable to allow something
like the following:
(proclaim (special *foo*))
(proclaim (integer *foo*))
or
(defvar *foo* 27 "Number of FOOs still to be used." 'integer)
This seems quite useful to me, and doesn't ruin the locality of lexical
bindings.
-- Scott
∂05-May-85 0909 RAM@CMU-CS-C.ARPA macr --> declares
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85 09:09:45 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Sun 5 May 85 12:09:47-EDT
Date: Sun, 5 May 1985 12:09 EDT
Message-ID: <RAM.12108607886.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Cc: common-lisp@SU-AI.ARPA, vanroggen@DEC-HUDSON.ARPA
Subject: macr --> declares
In-reply-to: Msg of 5 May 1985 11:53-EDT from Scott E. Fahlman <Fahlman>
The CLM seems to believe that type proclamations are legal. The
following example is on page 156:
(proclaim '(type float tolerance))
Rob
∂05-May-85 0919 FAHLMAN@CMU-CS-C.ARPA Misfeature: macros expanding into declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85 09:19:08 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 5 May 85 12:19:02-EDT
Date: Sun, 5 May 1985 12:18 EDT
Message-ID: <FAHLMAN.12108609568.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Tim McNerney <TIM@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Misfeature: macros expanding into declarations
In-reply-to: Msg of 4 May 1985 19:26-EDT from Tim McNerney <TIM at MIT-MC>
Although this "misfeature" makes life much harder on the Lisp implementor and
the macro writer, its semantics are not without utility. Let me illustate
this with a couple of simple examples:
If it were just a matter of making life harder on the Lisp implementor,
simple utility would probably be a sufficient argument. It is a fact,
lamented by some, that in the original Common Lisp design we were quite
willing to make the implementor go through incredible gyrations in order
to make things slightly more uniform or useful at the user level. This
has generally been accepted since, in many cases, this implementation
effort only had to be done once, in some public-domain implementaiton,
and all the others could then just copy the solution. It hasn't always
worked that way, but that was the motivation for letting certain
hard-to-implement things into the language.
This macro-expansion business is not just a one-shot implementation
problem, however. It is a rich source of bugs whose flow has shown no
sign of diminishing over time. It affects not just the hard-core
implementors, but anyone who wants to write macros or other source-level
tranformation or analysis tools. Not many people working at user level
understand everything you need to understand in order to do this right.
I'm not even 100% certain myself that a correct implementation is
possible. We keep finding subtle problems.
In addition to the problem of recurring bugs, it is clear that this is a
major contributor to poor performance in Common Lisp interpreters.
Given these problems, I think that we should only keep this mechanism if
people come up with important, non-imaginary uses for it that cannot
easily be done any other way. It seems a shame to keep such an evil
machanism in the language just because people can think up some clever
ways of using it.
-- Scott
∂05-May-85 0953 FAHLMAN@CMU-CS-C.ARPA macr --> declares
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85 09:53:21 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 5 May 85 12:53:23-EDT
Date: Sun, 5 May 1985 12:53 EDT
Message-ID: <FAHLMAN.12108615826.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: macr --> declares
Oops, looks like I'm confused again (with a little help from the
manual). There it is, right there on page 156: a type proclamation, big
as life. The text on page 158 describing the TYPE declaration specifier
seems to deny that such a thing is possible, since it says that this
specifier applies only to variable BINDINGS, but I think we ought to go
with page 156, since (as I was just arguing) this mechanism is clearly
useful.
I believe that our current Slisp compiler, and probably several
compilers derived from it, do not currently do anything with TYPE
proclamations, but it's a five-minute change to add this (I think). In
fact, type-restricted global specials were in there at one time, but
were ripped out when PROCLAIM came along.
-- Scott
∂05-May-85 1036 fateman%ucbdali@Berkeley mysterious declarations off in left field
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 5 May 85 10:36:43 PDT
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.46)
id AA15145; Sun, 5 May 85 10:35:39 pdt
Received: by ucbdali.ARPA (4.24/4.46)
id AA26300; Sun, 5 May 85 10:37:51 pdt
Date: Sun, 5 May 85 10:37:51 pdt
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8505051737.AA26300@ucbdali.ARPA>
To: Fahlman@CMU-CS-C.ARPA, vanroggen@DEC-HUDSON.ARPA
Subject: mysterious declarations off in left field
Cc: common-lisp@SU-AI.ARPA
Don't packages offer an alternative way of scoping declarations?
∂05-May-85 1112 FAHLMAN@CMU-CS-C.ARPA mysterious declarations off in left field
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85 11:12:26 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 5 May 85 14:12:19-EDT
Date: Sun, 5 May 1985 14:12 EDT
Message-ID: <FAHLMAN.12108630198.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: fateman%ucbdali@λBerkeley (Richard Fateman)λ
Cc: common-lisp@SU-AI.ARPA
Subject: mysterious declarations off in left field
In-reply-to: Msg of 5 May 1985 13:37-EDT from fateman%ucbdali at Berkeley (Richard Fateman)
Don't packages offer an alternative way of scoping declarations?
Sure, but packages normally function at a very large grain size.
Sometimes you want to add something to a package without having to scan
the whole package definition to ensure that some fool has not declared X
to be a quadruple-float. If I bind a lexical X, that's my X and I'm not
interested in anyone else's views about what type X's in general should
be.
-- Scott
∂05-May-85 1633 KMP@SCRC-STONY-BROOK.ARPA mysterious declarations off in left field
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 May 85 16:33:05 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 230444; Sun 5-May-85 19:31:32-EDT
Date: Sun, 5 May 85 19:30 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: mysterious declarations off in left field
To: Fahlman@CMU-CS-C.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12108630198.BABYL@CMU-CS-C.ARPA>
Message-ID: <850505193039.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Sun, 5 May 1985 14:12 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Don't packages offer an alternative way of scoping declarations?
Sure, but packages normally function at a very large grain size.
Sometimes you want to add something to a package without having to scan
the whole package definition to ensure that some fool has not declared X
to be a quadruple-float.
Or SPECIAL! I've already had problems in Macsyma source code with closures
that didn't "close" because someone decided STRING should be a special variable.
I guess you can imagine how that would be a pretty high-probability variable
name and a poor choice of special name ... Consider too that names like
LIST, STRING, etc. are not likely to be private -- nearly everyone is going
to inherit them from GLOBAL -- so the first time anyone in any "package"
declares one of them to be special, it screws everyone else who tries to do
compilations in that environment.
If I bind a lexical X, that's my X and I'm not interested in anyone
else's views about what type X's in general should be.
Indeed.
Actually, I wonder if we shouldn't have said that type proclamations
should pertain only to special variables. eg,
(PROCLAIM '(TYPE FLOAT TOLERANCE))
might have only applied to special occurrences of TOLERANCE. This would
mean that people using variables lexically in other modules would be far
less likely to find irrelevant declarations affecting them...
In cases where people wanted to make assertions about lexical variables,
they should perhaps have to scope such declarations lexically.
Although obviously such a change is somewhat incompatible, we might consider
it (or something like it) for the next round of revisions. (An alternate
approach which would achieve the same end would be to introduce a new
declaration operator which had the property of applying only to special
occurrences so that people could choose which style they wanted.)
Of course this doesn't solve the problem I alluded to earlier of having
people declare things special behind my back...
∂05-May-85 1739 FAHLMAN@CMU-CS-C.ARPA mysterious declarations off in left field
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85 17:39:26 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 5 May 85 20:38:55-EDT
Date: Sun, 5 May 1985 20:38 EDT
Message-ID: <FAHLMAN.12108700574.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: mysterious declarations off in left field
In-reply-to: Msg of 5 May 1985 19:30-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Or SPECIAL! I've already had problems in Macsyma source code with closures
that didn't "close" because someone decided STRING should be a special variable.
Well, in any future MACSYMA, that special would be named *STRING* and
would therefore be harmless, assuming that the author of the code
follows the suggested conventions. Quick conversions of old code are
unlikely to observe such restrictions, however, and for compatibility
reasons we stopped short of actually requiring specials to have funny
names or funny syntax around them.
Actually, I wonder if we shouldn't have said that type proclamations
should pertain only to special variables. eg,
(PROCLAIM '(TYPE FLOAT TOLERANCE))
might have only applied to special occurrences of TOLERANCE. This would
mean that people using variables lexically in other modules would be far
less likely to find irrelevant declarations affecting them...
I think we did say that. The description of (PROCLAIM '(TYPE ...)) on
page 156 says that "any variable names mentioned are assumed to refer to
the dynamic values of the variable. So a lexical binding of TOLERANCE
would not inherit this type restriction.
-- Scott
∂05-May-85 1742 SOLEY@MIT-MC Misfeature: macros expanding into declarations
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 17:42:18 PDT
Date: Sun, 5 May 85 20:42:51 EST
From: Richard Mark Soley <SOLEY@MIT-MC>
Subject: Misfeature: macros expanding into declarations
To: TIM@MIT-MC
cc: common-lisp@SU-AI, Fahlman@CMU-CS-C, RAM@CMU-CS-C,
isrlist@GYRE, sgr@SCRC-STONY-BROOK
In-reply-to: Msg of Sat 4 May 85 18:26:24 EST from Tim McNerney <TIM>
Message-ID: <[MIT-MC].486343.850505.SOLEY>
Date: Sat, 4 May 85 18:26:24 EST
From: Tim McNerney <TIM>
To: Fahlman at CMU-CS-C
cc: TIM, common-lisp at SU-AI, RAM at CMU-CS-C
Re: Misfeature: macros expanding into declarations
Date: Sat, 4 May 1985 07:36 EDT
From: Rob MacLachlan <RAM at CMU-CS-C.ARPA>
The Common Lisp feature of allowing a macro to expand into
declarations ought to be flushed; it complicates much code while
giving no useful return.
Although this "misfeature" makes life much harder on the Lisp
implementor and the macro writer, its semantics are not
without utility. Let me illustate this with a couple of simple examples:
Implementor, shmimplementor! I don't think we're trying to
optomize things for the implementor, but CERTAINLY we care about
the macro writer, 'cause that's EVERYBODY! One thing this
feature overlooks is the (admittedly bad) behavior of some macro
writers that write overly-circular code, in which too-early
expansion of macros kills the program. We've all seen the
garbage codes that must be loaded interpreted first and THEN
compiled; I've ported a couple of systems that depended on this
rubbish and had troubles because of the early macro expansion
(which I eventually had to turn off). I'll send anyone who cares
my wonderful Symbolics Common Lisp function
SI:BREAK-THE-SYSTEM-FOR-THE-SAKE-OF-NISP.
Anyway, at LEAST if we're going to continue to have this feature,
there must be some flag that is set when we're doing "early"
macro expansion so that the macro writer can tell how to expand,
i.e., *EXPANDING-FOR-DECLARATIONS*.
-- Richard Soley
∂05-May-85 1826 REM@IMSSS Restrictions on what macros may call, to avoid needing to preload file
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-May-05 17:26:23 PST (=GMT-8hr)
Date: 1985 May 05 17:24:22 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132157012100.G0353
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:Common-LISP@SU-AI.ARPA
Subject:Restrictions on what macros may call, to avoid needing to preload file
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up)
Today somebody mentionned the problem of having to preload a file of
macros interpreted (in the compiler environment) before being able to
compile that same file, because of the macros needing themselves.
I encountered a more subtle problem which likewise requires preloading
the file of macros. In my case I was being careful not to have a macro
depend on itself, but it did depend on EXPRs in the same file. Loading
the macro interpreted was fine, because first the macro and all needed
EXPRs were loaded, and then any use of the macro occurred, so at that
point everything needed to expand the macro-form was available. But
when compiling, only macros are loaded into the compiler environment,
EXPRs are merely compiled and written to output, not also loaded. Thus
when it came time to compile a function which contained the
macro-form, only the toplevel macro-expander, not the EXPRs called by
the macro-expander, were available. I found I had to pre-load the file
interpreted, then compile it. But then every time a macro was compiled
the second time around the compiler complained about duplicate macro
definitions. (This is with PSL, but the same general problem would
probably happen with any LISP.)
I'm on the verge of rewriting all my macros that have subfunctions to
avoid subfunctions entirely, hacking the same effect by generating
forms that contain sub-macros within them, thus the calling of
sub-expanders happens via the macro mechanism after the toplevel
macro-expander has returned a form to re-expand, rather than from
within the body of the toplevel macro-expander, and the sub-expanders
are all macros instead of EXPRs and thus automatically loaded into the
compiler environment without needing to be pre-loaded interpreted. Is
this change the best approach to avoid compiler hassles, or does CL
provide a way to assure that certain EXPRs will both be compiled to
the output file and loaded into the compiler environment so that one
wouldn't have to do my proposed change?
∂05-May-85 1837 MLY@MIT-MC Misfeature: macros expanding into declarations
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 18:37:15 PDT
Date: Sun, 5 May 85 21:37:38 EST
From: Richard Mlynarik <MLY@MIT-MC>
Subject: Misfeature: macros expanding into declarations
To: SOLEY@MIT-MC, common-lisp@SU-AI
Message-ID: <[MIT-MC].486426.850505.MLY>
[with additional comments by gsb@mc]
Date: Sun, 5 May 85 20:42:51 EST
From: Richard Mark Soley <SOLEY@MIT-MC>
Date: Sat, 4 May 85 18:26:24 EST
From: Tim McNerney <TIM>
Date: Sat, 4 May 1985 07:36 EDT
From: Rob MacLachlan <RAM at CMU-CS-C.ARPA>
The Common Lisp feature of allowing a macro to expand into
declarations ought to be flushed; it complicates much code while
giving no useful return.
It isn't that hard. It has at least some utility. I did it quite some
time ago when this whole mess originally came up n months ago (and
implemented the DOCUMENTATION declaration at the same time for reasons
which were discussed then).
Let's not rehash things discussed before, which is where the present
discussion seems to be leading.
Although this "misfeature" makes life much harder on the Lisp
implementor and the macro writer...
Only the wimpy ones.
[gsb: I don't actually see how this makes life "much" harder. The
whole deal of declaration parsing (or separation from the "body") is
enough of a pain, that adding in macroexpansion was fairly trivial.
Of course, NIL has its own set of internal "language tools" which
handle various levels of declaration hacking, but they don't really
amount to all that much. Obviously what we are lacking in CL are some
additional tools for dealing with declarations, macroexpansion, etc.]
Anyway, at LEAST if we're going to continue to have this feature,
there must be some flag that is set when we're doing "early"
macro expansion so that the macro writer can tell how to expand,
i.e., *EXPANDING-FOR-DECLARATIONS*.
I don't understand exactly what this means at all.
If the macro expands into "(declare ...)" then it is "exanding for
declarations" as far as I can tell.
[gsb: i don't understand the point of this either, particularly. I
can see a potential for lossage when there is pre-parsing and thus
macroexpansion performed at definition time rather than at runtime in
interpreted code.]
What -is- useful for a macro to know is whether it is being expanded
by the compiler or the interpreter or for some other random purpose
(mainly in order to make use of different error-reporting techniques,
particularly those of the compiler) This information is part of the
environment passed to the macroexpansion function and has been in NIL
and the LMIT Lispm software for some time.
[gsb: NIL uses the environment given to macro functions as a pointer
to more information than just the current set of macro definitions.
For instance, it is used by SETF which keeps separate databases for
runtime and compiletime definitions. We have a set of utilities for
dealing with this sort of thing trivially, and basically all one has
to do is pass around the macroexpansion-environment to keep the
context straight.]
∂05-May-85 1845 SOLEY@MIT-MC Misfeature: macros expanding into declarations
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 18:44:12 PDT
Date: Sun, 5 May 85 21:44:43 EST
From: Richard Mark Soley <SOLEY@MIT-MC>
Subject: Misfeature: macros expanding into declarations
To: MLY@MIT-MC
cc: common-lisp@SU-AI
In-reply-to: Msg of Sun 5 May 85 21:37:38 EST from Richard Mlynarik <MLY>
Message-ID: <[MIT-MC].486436.850505.SOLEY>
Date: Sun, 5 May 85 21:37:38 EST
From: Richard Mlynarik <MLY>
To: SOLEY, common-lisp at SU-AI
Re: Misfeature: macros expanding into declarations
[with additional comments by gsb@mc]
Date: Sun, 5 May 85 20:42:51 EST
From: Richard Mark Soley <SOLEY@MIT-MC>
Date: Sat, 4 May 85 18:26:24 EST
From: Tim McNerney <TIM>
Date: Sat, 4 May 1985 07:36 EDT
From: Rob MacLachlan <RAM at CMU-CS-C.ARPA>
The Common Lisp feature of allowing a macro to expand into
declarations ought to be flushed; it complicates much code while
giving no useful return.
Although this "misfeature" makes life much harder on the Lisp
implementor and the macro writer...
Only the wimpy ones.
I agree, and I don't care to heavily support wimpy implementors
(wimplementors?). My point is that we SHOULD support wimpy macro writers.
Anyway, at LEAST if we're going to continue to have this feature,
there must be some flag that is set when we're doing "early"
macro expansion so that the macro writer can tell how to expand,
i.e., *EXPANDING-FOR-DECLARATIONS*.
I don't understand exactly what this means at all.
If the macro expands into "(declare ...)" then it is "exanding for
declarations" as far as I can tell.
[gsb: i don't understand the point of this either, particularly. I
can see a potential for lossage when there is pre-parsing and thus
macroexpansion performed at definition time rather than at runtime in
interpreted code.]
Exactly. The point is, there are macros that don't want to be
expanded at interpreter-load (eval) time [i.e., when the DEFUN is
loaded], but only when the defun is compiled. REGARDLESS of the
fact that no DECLARE is returned.
What -is- useful for a macro to know is whether it is being expanded
by the compiler or the interpreter or for some other random purpose
(mainly in order to make use of different error-reporting techniques,
particularly those of the compiler) This information is part of the
environment passed to the macroexpansion function and has been in NIL
and the LMIT Lispm software for some time.
Exactly what I was proposing. But this sucker would have to be
well documented.
-- Richard
∂05-May-85 1849 SOLEY@MIT-MC Restrictions on what macros may call, to avoid needing to preload file
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 18:49:10 PDT
Date: Sun, 5 May 85 21:48:38 EST
From: Richard Mark Soley <SOLEY@MIT-MC>
Subject: Restrictions on what macros may call, to avoid needing to preload file
To: REM%IMSSS@SU-SCORE
cc: Common-LISP@SU-AI
In-reply-to: Msg of 1985 May 05 17:24:22 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>
Message-ID: <[MIT-MC].486449.850505.SOLEY>
Date: 1985 May 05 17:24:22 PST (=GMT-8hr)
From: Robert Elton Maas <REM at IMSSS.SU.EDU>
Sender: REM%IMSSS at SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-To: REM%IMSSS at SU-SCORE.ARPA (temporary until nameservers up)
To: Common-LISP at SU-AI.ARPA
Re: Restrictions on what macros may call, to avoid needing to preload file
Today somebody mentionned the problem of having to preload a file of
macros interpreted (in the compiler environment) before being able to
compile that same file, because of the macros needing themselves.
I encountered a more subtle problem which likewise requires preloading
the file of macros. In my case I was being careful not to have a macro
depend on itself, but it did depend on EXPRs in the same file. . . .
EXPRs are merely compiled and written to output, not also loaded. . .
I'm on the verge of rewriting all my macros that have subfunctions to
avoid subfunctions entirely, . . .
What's wrong with
(defmacro burble (blah ...) (burble-internal blah ...))
(EVAL-WHEN (EVAL COMPILE LOAD)
(defun burble-internal ...)
)
I use it all the time for exactly the problem you mentioned.
-- Richard
∂05-May-85 1948 FAHLMAN@CMU-CS-C.ARPA Misfeature: macros expanding into declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85 19:48:27 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 5 May 85 22:48:23-EDT
Date: Sun, 5 May 1985 22:48 EDT
Message-ID: <FAHLMAN.12108724147.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Richard Mlynarik <MLY@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Misfeature: macros expanding into declarations
It is probably not worthwhile to argue over whether the macro expansion
misfeature makes life MUCH harder or just somewhat harder for
implementors and macro-writers, and how kind we want to be to "wimpy"
implementors. I am curious to find out if the people who think this is
not very hard have really handled the problem correctly; after several
iterations on the Spice Lisp interpreter and assorted macros, we've
still got some problems, so it doesn't look easy to us.
The fact remains that this misfeature slows down the interpreter and it
has been the source of a steady stream of bugs. The people responsible
for these bugs include assorted users trying to write macros and some
fairly experienced Common Lisp implementors (including me). Given that,
I still think that if nobody comes forward with a better argument for
this stuff than the examples we've seen so far, it should be flushed.
To let something this hairy into the language just because it is "not
without some utility" was a serious mistake, and one that we can correct
now with very little impact on existing code.
-- Scott
∂05-May-85 2001 GSB@MIT-MC (setf (apply #'foo ...) ...)
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 20:01:11 PDT
Date: Sun, 5 May 85 23:01:39 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: (setf (apply #'foo ...) ...)
To: HEDRICK@RUTGERS
cc: common-lisp@SU-AI
Message-ID: <[MIT-MC].486573.850505.GSB>
[oohhh, unbalanced parentheses hurt my eyes!!! Was that message complete?]
What you say is true, but... The primary utility of SETF of APPLY is
with those things like AREF which take a variable number of arguments;
as a result, the inversion functions for them typically take the value
first rather than last, e.g.
(SETF (AREF a i j k ...) v) ==> (ASET v a i j k ...)
so you sort of get stuck with having to do the LET-binding hair anyway.
I don't know what your SETF code is like. NIL uses a SETF i wrote
which utilizes a slightly hacked version of the moon/bawden code
analysis and variable-substitution stuff. My experience is that it
does sufficiently well to rarely produce completely superfluous
bindings, and the rest are usually necessary or worthwhile. Should i
take it that your setf makes no use of code analysis/simplification
stuff?
∂05-May-85 2252 HEDRICK@RUTGERS.ARPA Re: (setf (apply #'foo ...) ...)
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 5 May 85 22:51:54 PDT
Date: 6 May 85 01:52:04 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: (setf (apply #'foo ...) ...)
To: GSB@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from "Glenn S. Burke <GSB@MIT-MC>" of 6 May 85 00:01:39 EDT
We use the Spice Lisp SETF.
-------
∂06-May-85 0834 gls%AQUINAS@THINK.ARPA SETF of APPLY
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 May 85 08:34:41 PDT
Received: by THINK.ARPA with CHAOS id AA14159; Mon, 6 May 85 11:33:39 edt
Date: Monday, 6 May 1985, 11:33-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: SETF of APPLY
To: common-lisp@sail
Cc: gls%AQUINAS@THINK.ARPA
Message-Id: <850506113354.1.GLS@DESIDERIUS.THINK>
Hedrick is quite correct that there is a glaring inconsistency
in what the manual says about SETF of APPLY. I think that what it
says ought to be approximately the truth, but it needs to be hedged
with something about the need to use LET to get the evaluation order
straight. It is of course precisely to avoid such messy details
that SETF is a canned primitive in the first place.
What would you think of the more complex strategy outlined below
as a replacement for some of the text on page 96?
The SETF method for the function <name> must be such that the
expansion of
(SETF (<name> <z1> <z2> ... <zn> <zrest>) <z0>)
uses the form <zrest> (or the generated variable that fronts for it)
only as the last argument in some number of function calls
(<any-function> <q1> ... <qn> <zrest>)
Every such function call in the expansion is altered to be
(APPLY #'<any-function> <q1> ... <qn> <zrest>)
For example, suppose that (SETF (AREF FOO (P) (Q) (R)) X) were to expand to
(LET* ((#:G0018 FOO)
(#:G0019 (P))
(#:G0020 (Q))
(#:G0021 (R)))
(ASET X #:G0018 #:G0019 #:G0020 #:G0021))
Then the expansion of (SETF (APPLY #'AREF FOO (P) (Q) (R)) X) would be
(LET* ((#:G0018 FOO)
(#:G0019 (P))
(#:G0020 (Q))
(#:G0021 (R)))
(APPLY #'ASET X #:G0018 #:G0019 #:G0020 #:G0021))
--Guy
∂06-May-85 0845 gls%AQUINAS@THINK.ARPA Macros -> declarations
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 May 85 08:45:14 PDT
Received: by THINK.ARPA with CHAOS id AA14271; Mon, 6 May 85 11:43:25 edt
Date: Monday, 6 May 1985, 11:43-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Macros -> declarations
To: common-lisp@sail
Cc: gls%AQUINAS@THINK.ARPA
Message-Id: <850506114342.2.GLS@DESIDERIUS.THINK>
I would be not at all unhappy if this feature were to go away.
I agree that Scott's assessment that it is unlikely that any
existing code (outside of diagnostic tests for this very feature)
would be harmed.
I am persuaded not at all by the argument that it is hard to implement.
I am mildly swayed by the efficiency considerations for the interpreter.
The convincing point to me, however, is that the facility is likely
to confuse macro-writers (who do, indeed, frequently find it necessary
to find the division point between declarations/documentation and body).
As a proposal separate from the question of eliminating the expansion
of macros into declarations, I suggest the following primitive
for consideration:
PARSE-BODY list
The list is treated as a body (a list of forms) that may have declarations
and a documentation string at its head.
Three values are returned. The first is some tail of the list,
the executable part of the body. The second value is a list
of declarations (lists whose car is DECLARE) at the head of the body.
The third value is the documentation string, or NIL if there was
no documentation string.
--Guy
∂06-May-85 0854 gls%AQUINAS@THINK.ARPA PROCLAIM and type declarations
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 May 85 08:54:39 PDT
Received: by THINK.ARPA with CHAOS id AA14309; Mon, 6 May 85 11:47:28 edt
Date: Monday, 6 May 1985, 11:47-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: PROCLAIM and type declarations
To: common-lisp@sail
Cc: gls%AQUINAS@THINK.ARPA
Message-Id: <850506114744.3.GLS@DESIDERIUS.THINK>
I believe that the sentences from page 156 about PROCLAIM covers
the case currently under debate:
Any variable names mentioned are assumed to refer to the dynamic values
of the variable.... Similarly, any function names mentioned are assumed
to refer to the global function definition.
In a later paragraph it is noted that PROCLAIM of SPECIAL is given an
unusual interpretation.
--Guy
∂06-May-85 0947 vanroggen@DEC-HUDSON macros --> declarations
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 6 May 85 09:47:30 PDT
Date: Mon, 06 May 85 12:48:36 EDT
From: vanroggen@DEC-HUDSON
Subject: macros --> declarations
To: ram@cmu-cs-c
Cc: common-lisp@su-ai
I think others have provided examples of their usefulness. However,
usefulness is not a sufficient criterion for inclusion in the language
(fortunately!). I don't understand why you ask me to provide an example
when I'd also like to have the feature removed.
---Walter
∂06-May-85 0953 vanroggen@DEC-HUDSON local declarations
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 6 May 85 09:51:59 PDT
Date: Mon, 06 May 85 12:53:00 EDT
From: vanroggen@DEC-HUDSON
Subject: local declarations
To: fahlman@cmu-cs-c
Cc: common-lisp@su-ai
What I was complaining about was the implication in the manual that
the following code was "not meaningful":
(TYPECASE X
(SIMPLE-STRING
(LOCALLY (DECLARE (SIMPLE-STRING X))
...))
...)
This local declaration isn't "off in left field somehwere"; it's
quite lexical. (I'm assuming X isn't SPECIAL; that problem has
been aired a number of times now.)
---Walter
∂06-May-85 1043 vanroggen@DEC-HUDSON SETF APPLY ...
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 6 May 85 10:43:01 PDT
Date: Mon, 06 May 85 13:44:06 EDT
From: vanroggen@DEC-HUDSON
Subject: SETF APPLY ...
To: hedrick@rutgers
Cc: common-lisp@su-ai
BIT and SBIT are two other Common Lisp functions which should work
inside SETF of APPLY, but they're the only other ones.
It seems to me that we could have both the newvalue passed as the
last arg of the setting function and the ability to do SETF of
APPLY if we would admit to a function, that I'll call APPLY-BUT-LAST,
that's just like APPLY, except that it's the next-to-last argument
that must be a list, and the last argument is just passed as the
last argument to the applied function. This won't help with
multiple-value-setfs (which I think don't belong in Common Lisp),
but it will allow SETF of APPLY of other named SETFable forms.
---Walter
∂06-May-85 1053 WHOLEY@CMU-CS-C.ARPA (setf (apply #'foo ...) ...)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85 10:52:23 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Mon 6 May 85 13:52:00-EDT
Date: Mon, 6 May 1985 13:51 EDT
Message-ID: <WHOLEY.12108888638.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Cc: common-lisp@SU-AI.ARPA, GSB@MIT-MC.ARPA
Subject: (setf (apply #'foo ...) ...)
Just for the record (and to maybe make things epsilon easier for other
implementors), (setf (apply #'aref ...) ...) in Spice Lisp turns into a call to
Lisp::%Aset, which takes its arguments in the new-element-is-last order,
instead of the Zetalisp order. That turned out to be just as easy for us.
Also, the Let bindings that Setf produces that it can't prove can go away are
examined by a general-purpose "Let optimizer" in our compiler, which does a
more thorough job of removing spurious bindings.
--Skef
∂06-May-85 1148 FAHLMAN@CMU-CS-C.ARPA local declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85 11:48:05 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 6 May 85 14:48:02-EDT
Date: Mon, 6 May 1985 14:47 EDT
Message-ID: <FAHLMAN.12108898844.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: vanroggen@DEC-HUDSON.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: local declarations
In-reply-to: Msg of 6 May 1985 12:53-EDT from vanroggen at DEC-HUDSON
Ah, I misunderstood what you were suggesting. Yes, to somehow be able
to specify the type of a lexical variable within a subset of that
variable's scope is indeed something that would be useful (though doing
one quick copy into a type-restricted LET variable doesn't seem too
bad).
It also was not totally clear whether you were areguing for keeping
themacro-to-declaration lossage or flushing it. Glad to hear you're on
the side of sanity.
-- Scott
∂06-May-85 1159 FAHLMAN@CMU-CS-C.ARPA SETF of APPLY
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85 11:58:50 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 6 May 85 14:58:12-EDT
Date: Mon, 6 May 1985 14:58 EDT
Message-ID: <FAHLMAN.12108900686.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Guy Steele <gls%AQUINAS@THINK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: SETF of APPLY
In-reply-to: Msg of 6 May 1985 11:33-EDT from Guy Steele <gls%AQUINAS at THINK.ARPA>
I like Guy's new formulation for the SETF of APPLY stuff.
One other thing that should be said is that SETF of APPLY of AREF is
required to work, regardless of how the AREF-setting function is
implemented internally. The main object of this stuff is to get this
one case to work, and yet an implementation is technically permitted to
implement the AREF setter in some way that does not fit into the
framework described.
-- Scott
∂06-May-85 1235 Moon@SCRC-YUKON.ARPA SETF of APPLY
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 6 May 85 12:35:16 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 123937; Mon 6-May-85 15:35:04-EDT
Date: Mon, 6 May 85 15:34 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: SETF of APPLY
To: Guy Steele <gls%AQUINAS@THINK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850506113354.1.GLS@DESIDERIUS.THINK>
Message-ID: <850506153459.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I agree with your proposed revised description of SETF of APPLY. The specific
code in our implementation of APPLY's SETF-method follows; it may be useful
in constructing the English description. This is not the whole SETF-method,
just the relevant code fragment.
(DEFINE-SETF-METHOD APPLY (FUNCTION &REST ARGS)
....
(SETQ FUNCTION (SECOND FUNCTION))
(MULTIPLE-VALUE-BIND (VARS VALS STORE-VARS STORE-FORM ACCESS-FORM)
(GET-SETF-METHOD-MULTIPLE-VALUE (CONS FUNCTION ARGS))
(LET ((LIST-VAR (LOOP FOR VAR IN VARS AND VAL IN VALS
WHEN (EQ VAL (CAR (LAST ARGS))) RETURN VAR)))
(OR (AND LIST-VAR
(EQ (CAR (LAST ACCESS-FORM)) LIST-VAR)
(EQ (CAR (LAST STORE-FORM)) LIST-VAR))
(ERROR "APPLY of ~S not understood as a generalized variable" FUNCTION))
While SETF of APPLY of AREF could be implemented some other way, not involving
the last argument to the original form remaining last in the access-form and
store-form, I think it is necessary for SETF of APPLY of a user-defined function
to work this way.
This is all certainly ugly, but I still think the alternative (a separate
DEFSETF system for functions seen inside APPLY) would be a lot worse.
∂06-May-85 1241 OLDMAN@USC-ISI.ARPA defconstant vs. lexical variables
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 6 May 85 12:41:00 PDT
Date: 6 May 1985 15:40-EDT
Sender: OLDMAN@USC-ISI.ARPA
Subject: defconstant vs. lexical variables
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA] 6-May-85 15:40:52.OLDMAN>
Page 69 of the CLM states:
"Once a name has been declared by defconstant to be constant, any
further assignment to or binding of that special variable is an
error. ... A compiler may also choose to issue warnings about
bindings of the lexical variable of the same name."
Question: How can I make a lexical binding of the thing if it's
implicitly proclaimed special by the defconstant?
Alternate question: Why don't we have a way of declaring
something locally lexical?
--Dan Oldman {Data General}
∂06-May-85 1347 gls%AQUINAS@THINK.ARPA local declarations
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 May 85 13:47:06 PDT
Received: by THINK.ARPA with CHAOS id AA01781; Mon, 6 May 85 16:45:33 edt
Date: Monday, 6 May 1985, 16:45-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: local declarations
To: vanroggen@DEC-HUDSON@THINK.ARPA, fahlman@cmu-cs-c
Cc: common-lisp@su-ai, gls%AQUINAS@THINK.ARPA
In-Reply-To: The message of 6 May 85 12:53-EDT from vanroggen at DEC-HUDSON at think
Message-Id: <850506164554.4.GLS@DESIDERIUS.THINK>
Date: Mon, 06 May 85 12:53:00 EDT
From: vanroggen@DEC-HUDSON@think
What I was complaining about was the implication in the manual that
the following code was "not meaningful":
(TYPECASE X
(SIMPLE-STRING
(LOCALLY (DECLARE (SIMPLE-STRING X))
...))
...)
This local declaration isn't "off in left field somehwere"; it's
quite lexical. (I'm assuming X isn't SPECIAL; that problem has
been aired a number of times now.)
---Walter
"Any REALLY good compiler" could figure this case out without needing
the explicit declaration. (But of course it can't figure out general
cases.)
You can get around this somewhat either by using LET or by using THE:
(TYPECASE X
(SIMPLE-STRING
... (CHAR (THE SIMPLE-STRING X) 43) ...)
...)
For true hair, use MACROLET:
(TYPECASE X
(SIMPLE-STRING
(MACROLET ((X () '(THE SIMPLE-STRING X)))
... (CHAR (X) 43) ...))
...)
[Yuk.]
--Guy
∂06-May-85 1444 Moon@SCRC-QUABBIN.ARPA Macros -> declarations
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 6 May 85 14:43:20 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 161094; Mon 6-May-85 17:40:21-EDT
Date: Mon, 6 May 85 17:43 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Macros -> declarations
To: Guy Steele <gls%AQUINAS@THINK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850506114342.2.GLS@DESIDERIUS.THINK>
Message-ID: <850506174305.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Monday, 6 May 1985, 11:43-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
I would be not at all unhappy if this feature were to go away.
I agree that Scott's assessment that it is unlikely that any
existing code (outside of diagnostic tests for this very feature)
would be harmed.
I have no opinion one way or the other about whether the feature of macros
expanding into DECLARE forms should be retained or flushed. Maybe we'll
hear from KMP what he had in mind when he suggested it, back in 1982 or
thereabouts, before we make a decision.
I would like to point out, though, that anyone claiming that no one uses
the feature is on very thin ice. A hell of a lot of copies of Common
Lisp: The Language have been sold. I have heard of more than one
implementation existing "off in left field". My experience has been
that users will often use features that you wouldn't have expected them
to use, or even discover, and then will get mad when you remove the
feature. The worst case of this, of course, is when the user thought it
was a feature and the implementor thought it was a bug.
I am persuaded not at all by the argument that it is hard to implement.
I am mildly swayed by the efficiency considerations for the interpreter.
I found it easy enough to implement an interpreter that handles these efficiently.
It pre-processes certain special forms the first time it encounters them. No
big deal.
The convincing point to me, however, is that the facility is likely
to confuse macro-writers (who do, indeed, frequently find it necessary
to find the division point between declarations/documentation and body).
As a proposal separate from the question of eliminating the expansion
of macros into declarations, I suggest the following primitive
for consideration:
PARSE-BODY list
The list is treated as a body (a list of forms) that may have declarations
and a documentation string at its head.
Three values are returned. The first is some tail of the list,
the executable part of the body. The second value is a list
of declarations (lists whose car is DECLARE) at the head of the body.
The third value is the documentation string, or NIL if there was
no documentation string.
This is a good suggestion. We already have this, but haven't documented it
pending standardization or other reasons why we might want to change it. Our
implementation of this raises some points:
- It needs to take a lexical environment argument so it can expand macros
so it can look for declarations.
- It needs to take an argument that tells it whether documentation strings
are allowed in this kind of body.
- It's convenient for the caller if PARSE-BODY peels off the DECLARE's and
simply returns a one-level list of declarations. The caller can cons
DECLARE back onto the front of this list if desired.
- For our system's applications, we found it convenient to split the
declarations into four kinds returned as separate lists. I don't
know that it would make sense to standardize this in Common Lisp,
though. The four kinds were SPECIAL declarations, type declarations,
declarations that need to be saved until run time for the Debugger
(not a portable concept), and all others.
∂06-May-85 1642 KMP@SCRC-STONY-BROOK.ARPA Macros -> declarations
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 6 May 85 16:42:24 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 231404; Mon 6-May-85 19:38:28-EDT
Date: Mon, 6 May 85 19:39 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Macros -> declarations
To: Moon@SCRC-STONY-BROOK.ARPA, gls%AQUINAS@THINK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850506174305.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <850506193941.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Mon, 6 May 85 17:43 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: Monday, 6 May 1985, 11:43-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
I would be not at all unhappy if this feature were to go away...
I have no opinion one way or the other about whether the feature of macros
expanding into DECLARE forms should be retained or flushed. Maybe we'll
hear from KMP what he had in mind when he suggested it, back in 1982 or
thereabouts, before we make a decision. ...
Thanks for reminding me about this. Indeed, I did have reasons other than the
ones I've seen mentioned thus far. I think that at least one possible use I
had in mind was for allowing macros so that you could create alternate syntax
for declarations. eg, suppose a BIT-REGISTER was some abstraction on special
variables that hold fixnums. Then
(DEFMACRO DECLARE-BIT-REGISTER (&REST NAMES)
`(DECLARE (SPECIAL ,@NAMES)
(FIXNUM ,@NAMES)))
might be something you could imagine writing and
(DEFUN FROB (REG)
(DECLARE-BIT-REGISTER REG)
(FROB-1))
(DEFUN FROB-1 ()
(DECLARE-BIT-REGISTER REG)
...)
might be a sample usage. Note that in this situation it is not the case that
DEFVAR or the like is called for, since we're only communicating between two
functions. Also, one may not want to write:
(DEFUN FROB (REG)
(DECLARE (SPECIAL REG) (FIXNUM REG))
(FROB-1))
(DEFUN FROB-1 ()
(DECLARE (SPECIAL REG) (FIXNUM REG))
...)
because that loses an abstraction level.
By the way, abstractions like my DECLARE-BIT-REGISTER do not provide "room for"
other declarations. Eg, consider:
(DEFUN FOO (REG)
(DECLARE-BIT-REGISTER REG)
(DECLARE (SPECIAL *FOO*))
...)
There is no way (without violating the BIT-REGISTER abstraction) to not write
two leading DECLAREs.
∂06-May-85 1721 WHOLEY@CMU-CS-C.ARPA Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85 17:21:06 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Mon 6 May 85 20:20:52-EDT
Date: Mon, 6 May 1985 20:20 EDT
Message-ID: <WHOLEY.12108959433.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA, gls%AQUINAS@THINK.ARPA,
Moon@SCRC-STONY-BROOK.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 6 May 1985 19:39-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Date: Monday, 6 May 1985 19:39-EDT
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Re: Macros -> declarations
By the way, abstractions like my DECLARE-BIT-REGISTER do not provide "room
for" other declarations. Eg, consider:
(DEFUN FOO (REG)
(DECLARE-BIT-REGISTER REG)
(DECLARE (SPECIAL *FOO*))
...)
There is no way (without violating the BIT-REGISTER abstraction) to not
write two leading DECLAREs.
So what's really wanted is a DEFDECLARATION or somesuch that works like DEFTYPE
in defining a macro-like thing that expands into a list of declare forms.
Although a scheme like this wouldn't eliminate the need for a body parser to
"macroexpand" stuff at runtime, it would eliminate the screw that was the last
straw to Rob MacLachlan -- the need for all macro writers to do &environment
hacking whenever parsing bodies.
(defdeclaration bit-register (&rest guys)
(mapcan #'(lambda (guy) `((special ,guy) (fixnum ,guy))) guys))
(defun foo (reg)
(declare (bit-register reg) (special *foo*))
...)
Note that there is no way to scope DEFTYPE's. With the above suggestion, there
would be no way to scope DEFDECLARATION's either. An alternate solution, which
requires only a one-word change to the language spec, is to restrict macros
that can expand into declarations to GLOBAL macros. This solution would handle
all of the imaginative uses for this feature that people here have come up
with, while removing the big ball of hair that makes it hard for users to write
correct macros.
This latter suggestion is ugly, I agree. A completely separate macro-like
mechanism is provided for types, and happens to prevent the definition of local
types, so why not have a similar mechanism for declarations?
--Skef
∂06-May-85 1744 HEDRICK@RUTGERS.ARPA SETF (APPLY
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 6 May 85 17:44:05 PDT
Date: 6 May 85 20:44:26 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: SETF (APPLY
To: common-lisp@SU-AI.ARPA
The problem with the current definition is that it depends upon the
implementation. Rather than kludging up the definition more so that
it properly describes hairier implementations of SETF, how about
simply saying that SETF (APPLY must work for AREF, BITS, and SBITS,
if those are the only useful cases. You might also say that it
is suggested that the implementation be such that this construct
should work for as many additional cases as possible. But I would
much rather have a specific list of those cases where it is supposed
to work than a description whose interpretation is implementation-
dependent. Currently, I can claim that I have implemented
SETF (APPLY correctly, since in my implementation there is no case
where the precondition would apply. I recently added special-case
code to handle AREF, and if people agree that BITS and SBITS are
also useful, I will add them too. I will use a strategy similar
to VanRoggen's suggested APPLY-BUT-LAST.
-------
∂06-May-85 1745 KMP@SCRC-STONY-BROOK.ARPA Macros -> declarations
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 6 May 85 17:44:51 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 231431; Mon 6-May-85 20:40:24-EDT
Date: Mon, 6 May 85 20:41 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Macros -> declarations
To: Wholey@CMU-CS-C.ARPA, KMP@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA, gls%AQUINAS@THINK.ARPA,
Moon@SCRC-STONY-BROOK.ARPA
In-Reply-To: <WHOLEY.12108959433.BABYL@CMU-CS-C.ARPA>
Message-ID: <850506204139.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Mon, 6 May 1985 20:20 EDT
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
Date: Monday, 6 May 1985 19:39-EDT
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Re: Macros -> declarations
By the way, abstractions like my DECLARE-BIT-REGISTER do not provide "room
for" other declarations. Eg, consider:
(DEFUN FOO (REG)
(DECLARE-BIT-REGISTER REG)
(DECLARE (SPECIAL *FOO*))
...)
There is no way (without violating the BIT-REGISTER abstraction) to not
write two leading DECLAREs.
So what's really wanted is a DEFDECLARATION or somesuch that works like DEFTYPE
in defining a macro-like thing that expands into a list of declare forms.
Although a scheme like this wouldn't eliminate the need for a body parser to
"macroexpand" stuff at runtime, it would eliminate the screw that was the last
straw to Rob MacLachlan -- the need for all macro writers to do &environment
hacking whenever parsing bodies.
(defdeclaration bit-register (&rest guys)
(mapcan #'(lambda (guy) `((special ,guy) (fixnum ,guy))) guys))
(defun foo (reg)
(declare (bit-register reg) (special *foo*))
...)
Note that there is no way to scope DEFTYPE's. With the above suggestion, there
would be no way to scope DEFDECLARATION's either. An alternate solution, which
requires only a one-word change to the language spec, is to restrict macros
that can expand into declarations to GLOBAL macros. This solution would handle
all of the imaginative uses for this feature that people here have come up
with, while removing the big ball of hair that makes it hard for users to write
correct macros.
This latter suggestion is ugly, I agree. A completely separate macro-like
mechanism is provided for types, and happens to prevent the definition of local
types, so why not have a similar mechanism for declarations?
--Skef
Well, that would certainly help a lot... but I'm not sure it would handle all
the useful cases.
For example, you couldn't use MACROLET to create a local declaration
type. We'd either need a DECLARATION-LET special form or we'd have to
say that all declaration types have to be global. I'm not taking a stand
on that issue; just pointing it out.
Another odd situation to consider is that you might be working in a package on which
it was desirable to shadow the symbol DECLARE for some reason. Rather than have
to write (LISP:DECLARE ...) everywhere, you could imagine wanting to do:
(DEFMACRO MY:DECLARE (&REST DECLS)
`(LISP:DECLARE ,@DECLS))
I don't expect this situation to be common early-on, but if people get into writing
embedded languages as macrofied extensions making heavy use of the package system,
they might well want such a provision ... or possibly something like:
(DEFMACRO MY:DECLARE (&REST DECLS)
`(LISP:DECLARE ,@(MY:TRANSLATE DECLS)))
It turns out that if anyone ever wants to recycle any of the names CL defines as
usable in declarations (like INTEGER, etc) to mean anything else in an embedded language,
they will need this sort of hook in order to avoid having to provide an intermediate
translator from their language to CL.
I could imagine Macsyma possibly wanting to play games like this if it were ever
really made to run "natively" in Common Lisp ... right now it has a lot of
intermediate translators that should not really be needed if the macro facility
of the underlying language is appropriately powerful.
By the way, I don't think that the frequency of parsing bodies (as opposed to
just propagating them) is so high as to make it offensive to have to use
&ENVIRONMENT in those situations.
∂06-May-85 1801 WHOLEY@CMU-CS-C.ARPA Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85 17:58:29 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Mon 6 May 85 20:58:16-EDT
Date: Mon, 6 May 1985 20:58 EDT
Message-ID: <WHOLEY.12108966237.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA, gls%AQUINAS@THINK.ARPA,
Moon@SCRC-STONY-BROOK.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 6 May 1985 20:41-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Date: Monday, 6 May 1985 20:41-EDT
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Re: Macros -> declarations
For example, you couldn't use MACROLET to create a local declaration
type. We'd either need a DECLARATION-LET special form or we'd have to
say that all declaration types have to be global. I'm not taking a stand
on that issue; just pointing it out.
Right -- there is no TYPE-LET special form, either, and that no one has missed
it! (I won't tell them if you don't.)
∂06-May-85 1804 Moon@SCRC-STONY-BROOK.ARPA SETF (APPLY
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 6 May 85 18:04:38 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 231446; Mon 6-May-85 21:00:53-EDT
Date: Mon, 6 May 85 21:04 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: SETF (APPLY
To: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 6 May 85 20:44-EDT from Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Message-ID: <850506210428.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 6 May 85 20:44:26 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
The problem with the current definition is that it depends upon the
implementation. Rather than kludging up the definition more so that
it properly describes hairier implementations of SETF, how about
simply saying that SETF (APPLY must work for AREF, BITS, and SBITS,
if those are the only useful cases.
Wait a minute. Those may be the only useful cases among the functions
listed in Common Lisp: The Language, but that doesn't mean that there
aren't user-defined functions that are equally as useful to SETF APPLY.
This is Lisp, the supposedly extensible and consistent language.
∂06-May-85 1830 HEDRICK@RUTGERS.ARPA Re: SETF (APPLY
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 6 May 85 18:28:55 PDT
Date: 6 May 85 21:29:06 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: SETF (APPLY
To: Moon@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from "David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>" of 6 May 85 21:04:00 EDT
I believe that we have two separate cases, each of which can be
described without implementation-dependent cruft:
(1) builtin SETF things. In this case there is a finite list, and we
should say which of these forms should work with SETF (APPLY.
(2) user defined SETF's. I believe that the most common cases
are those where the original language as in the manual works, except
instead of saying that they expand to the form (storefn zi1 .. zm),
say that the expansion is defined by a DEFSETF whose body is
of that form. (Probably that is what the original author was thinking.)
Again, you may want to suggest that other forms may be supported if
possible, but I believe the definition should be in terms of what
the user writes, not the actual expansion.
-------
∂06-May-85 1857 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85 18:57:04 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 6 May 85 21:56:46-EDT
Date: Mon, 6 May 1985 21:56 EDT
Message-ID: <FAHLMAN.12108976886.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 6 May 1985 20:41-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
The business about wanting to be able to shadow LISP:DECLARE seems
pretty weak to me. It seems reasonable to me that if people want to
redefine the essential structural symbols like DECLARE out from under
Common Lisp, then they should either be willing to say something like
LISP:DECLARE to get the old version or do a source-level transformation
on the surrounding form. There are a number of other structural
symbols, in addition to DECLARE, that are known to the interpreter, and
we can't very well macroexpand everything in sight in order to see if we
have one of these.
-- Scott
∂07-May-85 1118 BSG@SCRC-RIVERSIDE.ARPA Macros -> declarations
Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 7 May 85 11:17:45 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-RIVERSIDE.ARPA via CHAOS with CHAOS-MAIL id 38048; Tue 7-May-85 08:47:43-EDT
Date: Tue, 7 May 85 08:51 EDT
From: Bernard S. Greenberg <BSG@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Macros -> declarations
To: Fahlman@CMU-CS-C.ARPA, KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12108976886.BABYL@CMU-CS-C.ARPA>
Message-ID: <850507085122.9.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Mon, 6 May 1985 21:56 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
The business about wanting to be able to shadow LISP:DECLARE seems
pretty weak to me.
He's hardly shadowing Lisp:declare....
It seems reasonable to me that if people want to
redefine the essential structural symbols like DECLARE out from under
Common Lisp, then they should either be willing to say something like
LISP:DECLARE to get the old version or do a source-level transformation
on the surrounding form. There are a number of other structural
symbols, in addition to DECLARE, that are known to the interpreter, and
we can't very well macroexpand everything in sight in order to see if we
have one of these.
-- Scott
I don't buy this as a counterargument to what KMP said. Subsitute "DEFUN"
for "DECLARE" in the above paragraph. You can only define functions with
DEFUN -- (generic)Lisp provides no other way. Yet, we have the whole
top-level macro mechanism to allow you to define application-language-embedded
function-definers, calls to whom are expanded at top-level to ultimately
produce DEFUNs. DECLARE is the only way to declare things lexically.
The same arguments apply.
∂07-May-85 1139 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 May 85 11:38:56 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 7 May 85 14:08:50-EDT
Date: Tue, 7 May 1985 10:18 EDT
Message-ID: <FAHLMAN.12109112004.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "Bernard S. Greenberg" <BSG%scrc@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 7 May 1985 08:51-EDT from Bernard S. Greenberg <BSG at STONY-BROOK.SCRC.Symbolics.COM>
I don't buy this as a counterargument to what KMP said. Subsitute "DEFUN"
for "DECLARE" in the above paragraph. You can only define functions with
DEFUN -- (generic)Lisp provides no other way. Yet, we have the whole
top-level macro mechanism to allow you to define application-language-embedded
function-definers, calls to whom are expanded at top-level to ultimately
produce DEFUNs. DECLARE is the only way to declare things lexically.
The same arguments apply.
I guess I didn't make myself clear. I understand that macros are able
to provide suitable disguises for anything that takes the form of a list
to be evaluated, such as DEFUN, and that this is useful in creating
embedded sublanguages with a LIsp-like syntax. My point was that we do not
have anything like macros for disguising "structural" items that are not
in the form of lists to be evaluated: argument lists, things like
&optional, T and NIL, certain keywords, declarations, components of
declarations, doc strings, and so on. Various parts of the interpreter
look for such things verbatim, without doing any macro-expansion of
objects or structures that might turn into the item being sought.
That's good for efficiency, particularly in the presence of MACROLET,
and gives the human reader of Lisp code at least a few stable landmarks
to hold on to. The price is that if you really want to monkey around
with these structural things in an embedded language, you have to
transform the whole surrounding form and not just the item itself. To
me that seems like a reasonable price for those people who want an
embedded language that departs from Lisp syntax in such a deep way. If
you get rid of parentheses or prefix notation or argument lists, you'll
have to do a transformation on the whole form anyway; I'm just saying
that we could reasonably consider declarations to be something basic to
the syntax of the language, like argument lists, rather than thinking
of them as a funny kind of body form. Just because (DECLARE ...) looks
like any old lisp form, that doesn't mean we have to treat it as one.
-- Scott
∂07-May-85 1221 KMP@SCRC-STONY-BROOK.ARPA Macros -> declarations
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 May 85 12:20:52 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232005; Tue 7-May-85 15:16:41-EDT
Date: Tue, 7 May 85 15:17 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Macros -> declarations
To: Fahlman@CMU-CS-C.ARPA, BSG@TENEX.SCRC.Symbolics.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12109112004.BABYL@CMU-CS-C.ARPA>
Message-ID: <850507151759.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Tue, 7 May 1985 10:18 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Date: Tue, 7 May 85 08:51 EDT
From: Bernard S. Greenberg <BSG@STONY-BROOK.SCRC.Symbolics.COM>
I don't buy this as a counterargument to what KMP said. Subsitute "DEFUN"
for "DECLARE" in the above paragraph. You can only define functions with
DEFUN -- (generic)Lisp provides no other way. Yet, we have the whole
top-level macro mechanism to allow you to define application-language-embedded
function-definers, calls to whom are expanded at top-level to ultimately
produce DEFUNs. DECLARE is the only way to declare things lexically.
The same arguments apply.
I guess I didn't make myself clear. I understand that macros are able
to provide suitable disguises for anything that takes the form of a list
to be evaluated, such as DEFUN, and that this is useful in creating
embedded sublanguages with a LIsp-like syntax. My point was that we do not
have anything like macros for disguising "structural" items that are not
in the form of lists to be evaluated: argument lists, things like
&optional, T and NIL, certain keywords, declarations, components of
declarations, doc strings, and so on. Various parts of the interpreter
look for such things verbatim, without doing any macro-expansion of
objects or structures that might turn into the item being sought.
I guess the issue is whether you think of DECLARE as "structural". Consider:
(DEFMACRO FROB (WIDGET)
(COND ((> MOST-NEGATIVE-FIXNUM something)
...expansion that assumes WIDGET was represented as a fixnum...)
(T
...expansion that assumes WIDGET was represented as a list...)))
(DEFMACRO DECLARE-WIDGET (&REST NAMES)
`(DECLARE (TYPE ,(IF (> MOST-NEGATIVE-FIXNUM something) 'FIXNUM 'LIST) ,@NAMES)))
(DEFUN FOO (X)
(DECLARE-WIDGET X)
... (FROB X) ...)
Certainly I need as a minimum the ability to do this. It is not reasonable
(as you seem to be proposing) that I should have to do:
(DEFMACRO DEFINE-WIDGET-OPERATION (NAME BVL &BODY FORMS)
`(DEFUN FOO ,BVL
(DECLARE ...hair to parse &WIDGET keywords in BVL
or DECLARE-WIDGET magic at head of FORMS...)
,@FORMS))
since it is not compositional -- ie, if I have a similar DEFINE-GIZMO-OPERATION
macro, I cannot easily define something which frobs both gizmos and widgets.
Hence, I claim the declaration is not structural in the sense that, for example,
a COND clause is.
By the way, Macsyma does this sort of thing with read-conditionals because
languages don't allow it the flexibility to do it any other way. I hope I don't
have to explain to you how and why this offends me.
By the way, Skef's proposal (for "declaration macros") handles this problem, too.
I'm just a little skeptical about a special-purpose declaration macro just
for this context. Certainly it is the minimum potentially acceptable position,
since it at least tries to address the issues I'm raising rather than sweeping
them under the rug. I'm a little afriad that next people will want COND macros
and LAMBDA macros (oops, the LispM has them already) and ... but I might yet be
willing to yield to the suggestion of these declaration macros -- I'm still
thinking about it in light of some of the problems I mentioned in my last message.
That's good for efficiency, particularly in the presence of MACROLET,
and gives the human reader of Lisp code at least a few stable landmarks
to hold on to. The price is that if you really want to monkey around
with these structural things in an embedded language, you have to
transform the whole surrounding form and not just the item itself. To
me that seems like a reasonable price for those people who want an
embedded language that departs from Lisp syntax in such a deep way. If
you get rid of parentheses or prefix notation or argument lists, you'll
have to do a transformation on the whole form anyway; I'm just saying
that we could reasonably consider declarations to be something basic to
the syntax of the language, like argument lists, rather than thinking
of them as a funny kind of body form. Just because (DECLARE ...) looks
like any old lisp form, that doesn't mean we have to treat it as one.
I just don't buy this claim that it's an efficiency issue. Moon's recent
messages claims this was done efficiently on the Lisp Machine.
Experience with Scheme likewise suggests this can be done efficiently.
You only have to do it once when the form is first seen by the
interpreter and never again. There's no loss of efficiency there. In
fact (leaving aside the question of macrofied declares for the context
of this sentence), if you are lazily or repeatedly expanding macros,
you're risking having a function change its behavior in midstream on any
expression involving macros, which I'd claim is a violation of the maxim
that interpreted and compiled code should execute the same for legal
expressions.
∂07-May-85 1319 REM%IMSSS.#Pup@SU-SCORE.ARPA Read macros vs. macro-->declare
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 7 May 85 13:19:18 PDT
Received: from IMSSS by Score with Pup; Tue 7 May 85 13:19:08-PDT
Date: 7 May 1985 1319-PDT
From: Rem@IMSSS
Subject: Read macros vs. macro-->declare
To: COMMON-LISP%SU-AI@SCORE
I agree that read macros aren't the right thing, i.e. something like
#<MACRO>(FOO ...) expanding at read time into (DECLARE (SPECIAL FROB)
(INTEGER FROB)) loses because it forces the macro-expansion environment
to be the read environment instead of the compiler environment, which
may not be exactly the same. But would it be feasible to have a
continuation read-macro that produces a scheme-style continuation that
gets evaluated the first time anybody tries to perform an operation
upon it, even a trivial one like PAIRP? Then you could with this single
facility have macros that expanded into arglists, or into declarations,
or into arbitrary sequences of forms spliced into bodies of functions,
or into COND clauses, or into function names, or into type names,
or into any other sub-expression or splice-list? The programmer would
have to be careful not to try to do an operation on the continuation-ptr
until such time as the correct macro-expansion operation is in effect.
-------
∂07-May-85 1350 KMP@SCRC-STONY-BROOK.ARPA Read macros vs. macro-->declare
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 May 85 13:49:52 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232132; Tue 7-May-85 16:43:19-EDT
Date: Tue, 7 May 85 16:44 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Read macros vs. macro-->declare
To: Rem%IMSSS@SU-SCORE.ARPA, COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 7 May 85 16:19-EDT from Rem@IMSSS
Message-ID: <850507164439.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 7 May 1985 1319-PDT
From: Rem@IMSSS
Subject: Read macros vs. macro-->declare
To: COMMON-LISP%SU-AI@SCORE
... would it be feasible to have a continuation read-macro that
produces a scheme-style continuation that gets evaluated the first time
anybody tries to perform an operation upon it, even a trivial one
like PAIRP?
You're already (implicitly) performing "an operation" upon it if you
assume the expression is code at all. The bad part about readmacros
is that they force me to think "language semantics" at times when I might
only want to think "symbol manipulation". eg, I can't write an editor
utility which calls normal READ to get
(DEFUN FOO (X) #+LISPM X #-LISPM (1- X))
out of the buffer, manipulate the expression, and PRINT it back into
the buffer with any hope it that it will run on a system with different
characteristics than those I used to edit it. Here the expression is
not code but data. Something along the lines of
(DEFUN FOO (X)
(IF-FEATURE LISPM X (1- X)))
works much better because you can READ-manipulate-PRINT it all day
without worrying that it's code, then can READ-COMPILE-FASDUMP or
READ-ABSORB-EXECUTE the processed code in some other system than
you did the original processing in without fear that you've lost a
read conditional.
By the way, this made me think of an interesting point on a slightly
different point, which is that one might imagine files full of (non-program)
symbolic data which want to be read in certain package, but which because
it will never be EVAL cannot use the IN-PACKAGE strategy. That's another
example of inferring too strongly that anything that will be seen by
READ must be code and another argument for -*- ... Package: ... -*-
rather than IN-PACKAGE. ie, I'd rather use
;;; -*- Package: KEYWORD; -*-
;;; My data file
(3 FOO BAR 7)
(16.0 3/7 (X Y Z))
and be able to just repeatedly call READ on the file contents than
continually do some kludge to look for an IN-PACKAGE form at the head
of data files, as in:
;;; My data file
(IN-PACKAGE "KEYWORD")
(3 FOO BAR 7)
(16.0 3/7 (X Y Z))
or worse
(IN-PACKAGE "JOE")
(EXPORT '(...))
(3 FOO BAR 7)
where it might be ambiguous whether EXPORT, etc. are part of the package
spec or part of the data.
-kmp
∂07-May-85 1951 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 May 85 19:50:50 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 7 May 85 22:50:34-EDT
Date: Tue, 7 May 1985 22:50 EDT
Message-ID: <FAHLMAN.12109248831.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Kent M Pitman <KMP%SCRC@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 7 May 1985 15:17-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
OK, I never doubted that people could make up cases where this macro ->
declare expansion appears to be useful. I just doubted that it really
would be an important mechanism in practice, or at least important
enough to justify the pain it causes.
Is there any hope that we can all agree on flushing macro -> declaration
expansion and replacing it with something like Skef's "declaration
macro" proposal? You state that this is the minimum acceptable position
(minimun acceptable amount of hair, I guess), and for me it's about the
maximum acceptable position. It would seem to cover about 99% of the
cases where people claim that they need the macro expansion.
I agree that if taken to the logical extreme, this proliferation of
specialized macro-like forms is bad news. On the other hand, one might
argue that macroexpanding potential declarations is also the start of a
slippery slide that, if taken to the logical extreme, could be equally
disastrous. Maybe we could try to solve the problem at hand and agree
that taking things to their logical extremes is probably a bad idea in a
language this complex and this full of compromises.
-- Scott
∂07-May-85 2237 hoey@nrl-aic Re: SETF of APPLY
Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 7 May 85 22:37:04 PDT
Message-Id: <8505080536.AA10133@nrl-aic>
Date: 7 May 1985 22:16:42 EDT (Tue)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: SETF of APPLY
To: common-lisp@SU-AI.ARPA
I like Guy's new text much more than the existing page 96, and after
reading Moon's code I believe it almost states the criterion for a
setf-applyable function correctly. The problem is that it obscures
with faint emphasis its major point. I read the statement:
The SETF method for the function <name> must be such that the
expansion of
(SETF (<name> <z1> <z2> ... <zn> <zrest>) <z0>)
uses the form <zrest> (or the generated variable that fronts for it)
only as the last argument in some number of function calls
(<any-function> <q1> ... <qn> <zrest>) <1>
as the definition for a setf-applyable function, and the statement
Every such function call in the expansion is altered to be
(APPLY #'<any-function> <q1> ... <qn> <zrest>) <2>
as the beginning of an explanation of what it does. But by examining
the code I realize that the latter statement is the main point: that
when those forms <1> get alterated to <2> their semantics must change
analogously to the alteration of
(<name> <x1> <x2> ... <xn> <zrest>)
to
(APPLY #'<name> <x1> <x2> ... <xn> <zrest>)
or the SETF will do something bizarre. For instance, if <any-function>
has <n+1> required arguments and <zrest> turns out to be NIL, the
expansion will be in error.
Forgive the impulsive radicality of a neophyte but I think this
restriction needs an explanation that is not feasible until SETF
methods are introduced. I would much rather see page 96 say something
like
o A call to APPLY of the form (APPLY #'<name> {arg}* <others>)
where <name>, has a ``SETF method'' amenable to APPLY, as
described at the end of this section. The only functions whose
SETF expansions are defined by Common Lisp to have this form are
AREF, BIT, and SBIT.
As an example, suppose that the variable INDEXES ....
Then somewhere around page 106 the real bag of worms can be dumped on
the table:
When
(APPLY #'<name> <x1> <x2> ... <xn> <rest>)
is used as a generalized variable, the SETF method for APPLY will
access the SETF method for <name> with exactly <n+1> arguments:
(GET-SETF-METHOD '(<name> <x1> <x2> ... <xn> <zrest>))
that is, with the final argument to APPLY--and thus a list of final
arguments to <name>--replaced by a single final argument to <name>.
The storing and accessing forms returned by the SETF method must
refer to the temporary variable <temp-rest> corresponding to <zrest>
only as the last argument to a function:
(<func> <q1> <q2> ... <qm> <temp-rest>)
Each such function call will be altered when used in the SETF
method of APPLY to be
(APPLY #'<func> <q1> <q2> ... <qm> <temp-rest>)
replacing the final argument to <func> by a list of final arguments.
For (APPLY #'<name> <x1> <x2> ... <xn> <rest>) to be used as a
generalized variable to be meaningful, the transformation
described above must produce a correct SETF method for it.
I think it important that <x1> ... <xn> be guaranteed to be passed
verbatim in case their structure matters.
It might help to put the actual code for the APPLY SETF method in.
Further desiderata:
I wish there were some way for the author to declare that a SETF method
is or is not amenable to APPLY, and for a SETF method to determine
whether it is expanding for APPLY. This might be done by promising
that APPLY's SETF method will use `(:MORE-ARGS ,(gensym)) for <zrest>
above.
Shouldn't <name>'s SETF method to be restricted to at most <n> required
and optional arguments, modulo destructuring? Should
(SETF (APPLY #'AREF (CONS FOO INDEXES)) NEWVALUE)
be allowed, or should it be required to be written
(SETF (APPLY #'AREF FOO INDEXES) NEWVALUE)
as on page 97? As it is, the code apparently works for the former only
by the accident that the SETF method for AREF could be (or is?) defined
with only an &REST argument:
(DEFINE-SETF-METHOD AREF (&REST AREF-FORM)
(LET ((STORE (GENSYM))
(AREF-FORM-TEMP (LOOP FOR ARGUMENT IN AREF-FORM
COLLECT (GENSYM))))
(VALUES AREF-FORM-TEMP
AREF-FORM
(LIST STORE)
`(ASET ,STORE ,@AREF-FORM-TEMP)
`(AREF ,@AREF-FORM-TEMP))))
Dan
∂08-May-85 0835 JLW PARSE-BODY
To: gls%aquinas@THINK.ARPA
CC: common-lisp@SU-AI.ARPA
Re your message of 6-May-85 11:43 EDT
About a year and a half ago, I wrote such a internal utility for Interlisp-D.
Then I discovered that Ron Kaplan had also written a similar utility
a year or two prior. The unfortunate thing is that neither of us
managed to get our "utilty" promoted to user-level status, and docmented
for all to use and not re-invent.
Isn't it about time for somebody in the Common Lisp community to implement
it, and put it into (at least) the yellow pages?
Once that is done, then the only argument against macro-expansions
producing DECLAREs and docmentation-strings is the potential for
confusion with side-effect-producing macros. I'm in favor of ignoreing
this problem (worrying about multiple side-effects from macro expansions)
but some others are more concerned.
-- JonL --
∂08-May-85 0859 RWK@SCRC-STONY-BROOK.ARPA Macros -> declarations
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 May 85 08:52:55 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232642; Wed 8-May-85 11:48:51-EDT
Date: Wed, 8 May 85 11:53 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Macros -> declarations
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: Kent M Pitman <KMP@TENEX.SCRC.Symbolics.COM>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12109248831.BABYL@CMU-CS-C.ARPA>
Message-ID: <850508115301.3.RWK@CROW.SCRC.Symbolics.COM>
Date: Tue, 7 May 1985 22:50 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Is there any hope that we can all agree on flushing macro -> declaration
expansion and replacing it with something like Skef's "declaration
macro" proposal? You state that this is the minimum acceptable position
(minimun acceptable amount of hair, I guess), and for me it's about the
maximum acceptable position. It would seem to cover about 99% of the
cases where people claim that they need the macro expansion.
Might I suggest another proposal that I think adds less complexity
for the same gain (for either side of the issue)?
Instead of DECLARE forms being allowed to be macros, why not allow the
forms INSIDE declare forms be macros? Using macros rather than
"declaration macros" lets you then use macrolet, and avoids the need for
any new "DEFDECLARE" special forms to document or implement.
This doesn't quite cover the bases, though, unless we also deal with
expanding into multiple declarations [i.e. (REGISTER X) ->
(SPECIAL X) (FIXNUM X)].
I'll propose two ways to deal with that.
1) Allow (DECLARE (FOO X) ((SPECIAL X) (FIXNUM X))) to mean the
same as (DECLARE (FOO X) (SPECIAL X) (FIXNUM X))
2) Allow (DECLARE (FOO X) (DECLARE (SPECIAL X) (FIXNUM X))). I.e.
Allow DECLARE as a declaration containing declarations.
∂08-May-85 0919 JLW ... point on a different point
To: kmp@MIT-MC.ARPA
CC: common-lisp@SU-AI.ARPA
Re your message of 7-May-85 16:43 EDT
in your defense of
;;; -*- Package:...
;;; my data file
over
;;; my data file
(in-package ...)
you seem to be arguing as though the former happens at a level below READ,
and is thus unambiguous, whereas th latter is ambiguous since the form
(in-package ...)
could be data for the application program.
I don't see any such permission for READ mentioned in th CL manual. In fact,
I have on numerous ocasions wanted to open a file and read character-by-character
to get a "close" look at the first few lines; and then call READ.
Isn't the right decomposition of functionality here to have a system-supplied
function called, say, READ-AND-DO-FILE-ATTRIBUTES; then LOAD would call it
on source files, and lusers who have random data files would make the
determination of attribute-information or data programmatically. I.e.,
the mere act of opening a file, or reading from it, would not, by itself,
do the READ-AND-DO-FILE-ATTRIBUTES; but th luser can call it, either at
top-level, or from some lower-level program.
-- JonL --
∂08-May-85 1121 FAHLMAN@CMU-CS-C.ARPA ... point on a different point
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 May 85 11:20:35 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 8 May 85 14:19:28-EDT
Date: Wed, 8 May 1985 14:19 EDT
Message-ID: <FAHLMAN.12109417898.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Jon White <JLW@SU-AI.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: ... point on a different point
In-reply-to: Msg of 8 May 1985 12:19-EDT from Jon White <JLW at SU-AI.ARPA>
Isn't the right decomposition of functionality here to have a system-supplied
function called, say, READ-AND-DO-FILE-ATTRIBUTES; then LOAD would call it
on source files, and lusers who have random data files would make the
determination of attribute-information or data programmatically.
If by "system-supplied" you mean a part of the Common Lisp
specification, I don't think that we should elevate the current concept
of file attributes and mode lines to the status of a language feature if
we can possibly avoid this. To establish this convention by treaty
among the suppliers of Common Lisps with Lisp-Machine-like environments
would be OK, however.
-- Scott
∂08-May-85 1513 RPG Proposal
To: quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA,
squires@USC-ISI.ARPA
I'd like to make a proposal regarding validation, but I want
to run it by you folks first to see whether there are too many
negatives before I run it past everyone.
I'd like to propose that there be a 2-stage validation
process. A group of hackers would be contracted to
collect and perform validation tests. This group would apply the
validation suite in an `intelligent' manner, producing a report
which stated what parts of common lisp: 1. are ok, 2. are not ok,
3. are missing, 4. are stretching the definition. These would be backed
up be specific tests that passed, failed, etc. This report, along with
a representative of the testing agency, would go before the validation
group, which would look at the report and any possible recommendations
the testing agency would have, and decide whether the Lisp passed overall
or was required to fix some things.
The idea would be that the testing agency would not hide the test results
from the tested-Lisp implementors, and that the report would be open to
scrutiny, and the testers subject to questioning.
Now, why such a complex setup? The fact is that the companies have
all the talent and test code. Lucid's test suite is around 10k non-trivial
lines of test code already. We would be willing to act as the test agency
at the outset. We estimate that we could start testing Lisps within 2 months
from today, once our test suite is a little better.
To validate our common lisp, we would let the validation committee run,
or observe us running, the proposed test suite over it. The test suite
would be available for the validation committee to review. Or something fair.
I think that without some group, like us, stepping forward, the validation
effort will not get very far. I'm not so much interested in validation
per se, but I am concerned with `false advertising' to users about what they
are getting.
So, if there are any comments about this proposal, I'd like to air them
in this forum before general discussion.
-rpg-
∂08-May-85 1843 FAHLMAN@CMU-CS-C.ARPA Proposal
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 May 85 18:43:30 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 8 May 85 21:43:34-EDT
Date: Wed, 8 May 1985 21:43 EDT
Message-ID: <FAHLMAN.12109498777.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA, squires@USC-ISI.ARPA
Subject: Proposal
In-reply-to: Msg of 8 May 1985 18:13-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
Dick,
If I understand your proposal, you are trying to set up some way to do
validation of Common Lisp without actually making the official
validation suite available to the public.
If that's what you're saying, I think it is a bad idea. With some sort
of official validation suite available to the public it will be very
easy for everyone, including random customers, to determine which
implementations are OK and which are deficient in various respects. We
would still need a bit of machinery for officially blessing
implementations, but it can be very simple. Public validation code also
makes it possible for implementors to see what is required, and will
serve to resolve some of the ambiguities in the manual. With secret,
proprietary validation code, we get none of these advantages;
implementors will be stuck with debugging their systems by generate and
test.
Of course, if nobody gets to work doing this public validation suite,
and if all the companies choose to hang on to their own proprietary
validation code, then your plan may be the only option. But it seems to
me that the advantages of having a body of validation code available to
the public are so great that even if companies hold onto their own code,
it is worth the effort of duplicating it. In that case, the companies'
internal testing code would have no official standing, though it might
be of value to them for internal testing. If there were money
available, perhaps the companies could be paid for throwing their
validation code into the pool, and thus could get something back on
their investment.
I suffered a minor setback here when two of my hand-trained undergrads
left for more lucrative jobs this summer. Were it not for that, I could
have offered to do a big chink of a validation suite here this summer.
I still may be able to do this -- I've got a couple of very good
high-school kids working for me, but they are new and I don't know how
soon they will be ready to write serious validation code. If ISI gets
the support contract for Common Lisp, they can do some of this as well.
-- Scott
∂08-May-85 2159 TIM@MIT-MC Lack of EQUALP hash tables
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 8 May 85 21:59:35 PDT
Date: Thu, 9 May 85 01:00:05 EST
From: Tim McNerney <TIM@MIT-MC>
Subject: Lack of EQUALP hash tables
To: common-lisp@SU-AI
Message-ID: <[MIT-MC].492730.850509.TIM>
I noticed that EQUALP is no included in the set of valid :TEST's for
hash tables (CLTL p. 282). What was the motivation behind this? An
EQUALP hash table seems like a perfectly reasonable type of hash table
to want, especially in applications where floating-point numbers and
integers are intermixed. Implementing the many to one hashing
function seems to be a bit tricky, but not insurmountable. Am I
missing something?
∂08-May-85 2246 RPG Fahlman's comments
To: quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA,
squires@USC-ISI.ARPA
The point of keeping (some) of the validation code `secret' is to
make sure that people don't cheat and get exactly the validation
code to work. I believe that is approximtely owow ADA is done.
I would also be in favor of doing it exactly the way ADA is done:
have a public validation suite along with a `secret' one. When the
public one has passed, the public and the private ones are applied
by the testors.
In fact, there is no `proprietariness' to it at all. The validation
suite that would be used for this purpose, if done the way I suggest,
would be government property.
-rpg-
∂09-May-85 0511 GJC@MIT-MC
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 9 May 85 05:11:14 PDT
Date: Thu, 9 May 85 08:11:50 EST
From: George J. Carrette <GJC@MIT-MC>
To: TIM@MIT-MC
cc: COMMON-LISP@SU-AI
Message-ID: <[MIT-MC].493032.850509.GJC>
EQUALP hash tables were absolutely essential in keeping LMI in
business, maybe thats why they were excluded. But seriously folks, the
digital CAD program we use in-house, "NewDraw," broke when moving from
pre-common-lisp system to post-common-lisp. Right at the time when
major new hardware development was going on, and the "NewDraw" users
wanted to move to post-common-lisp because of vast speed improvements
such as microcoded ethernet. There clearly wasnt any time for major
rewrites, so that the only thing to do was to change all functions
which inductively called EQUAL in the pre-common-lisp to ones that
call EQUALP in the new system. EQUAL => EQUALP, and ASSOC =>
ASSOC-EQUALP are the kind of obvious cases, but the program still
didnt work until a clever hardware engineer realized that he was being
screwed by hash table lookup, and changed MAKE-HASH-TABLE :TEST 'EQUAL
=> :TEST 'EQUALP. Which of course didnt work until a software person
implemented it.
The problem was that (EQUAL "foo" "FOO") used to be T, but now is NIL,
and all the hardware databases had chip and signal names in both
upper and lowercase, depending on what the user first typed in.
So from practical experience I can definitely put in a vote for
having :TEST 'EQUALP in hash tables.
-gjc
∂09-May-85 0622 RAM@CMU-CS-C.ARPA Lack of EQUALP hash tables
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 May 85 06:22:26 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 9 May 85 09:22:32-EDT
Date: Thu, 9 May 1985 09:22 EDT
Message-ID: <RAM.12109626021.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Lack of EQUALP hash tables
In-reply-to: Msg of 9 May 1985 02:00-EDT from Tim McNerney <TIM at MIT-MC>
I think an Equalp hashtable would also be useful because it would
allow you to use arrays and structures as keys.
In my code I have never had any great use for the case-insensitiveness
of equalp, since I use string-equal. In fact, I think it would be
useful if there was a predicate which used eql for comparison and
descended into arrays and structures. There have been a number of
times when I could have used such a function.
Rob
∂09-May-85 0643 BSG@SCRC-STONY-BROOK.ARPA Macros -> declarations
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 May 85 06:41:05 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 233367; Thu 9-May-85 09:36:59-EDT
Date: Thu, 9 May 85 09:43 EDT
From: Bernard S. Greenberg <BSG@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Macros -> declarations
To: RWK@YUKON.SCRC.Symbolics.COM, Fahlman@CMU-CS-C.ARPA
cc: KMP@TENEX.SCRC.Symbolics.COM, common-lisp@SU-AI.ARPA
In-Reply-To: <850508115301.3.RWK@CROW.SCRC.Symbolics.COM>
Message-ID: <850509094320.7.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Wed, 8 May 85 11:53 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Instead of DECLARE forms being allowed to be macros, why not allow the
forms INSIDE declare forms be macros? Using macros rather than
"declaration macros" lets you then use macrolet, and avoids the need for
any new "DEFDECLARE" special forms to document or implement.
This doesn't quite cover the bases, though, unless we also deal with
expanding into multiple declarations [i.e. (REGISTER X) ->
(SPECIAL X) (FIXNUM X)].
I'll propose two ways to deal with that.
1) Allow (DECLARE (FOO X) ((SPECIAL X) (FIXNUM X))) to mean the
same as (DECLARE (FOO X) (SPECIAL X) (FIXNUM X))
2) Allow (DECLARE (FOO X) (DECLARE (SPECIAL X) (FIXNUM X))). I.e.
Allow DECLARE as a declaration containing declarations.
3) Allow (DECLARE (PROGN .....)) [The onus of history.]
At any rate, RWK's whole proposal seems to cover all bases.
∂09-May-85 0900 DCP@SCRC-STONY-BROOK.ARPA hash table types
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 May 85 09:00:17 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 233515; Thu 9-May-85 11:56:12-EDT
Date: Thu, 9 May 85 12:01 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: hash table types
To: George J. Carrette <GJC@MIT-MC.ARPA>
cc: TIM@MIT-MC.ARPA, COMMON-LISP@SU-AI.ARPA
In-Reply-To: <[MIT-MC].493032.850509.GJC>
Message-ID: <850509120102.8.NFEP@NEPONSET.SCRC.Symbolics.COM>
Date: Thu, 9 May 85 08:11:50 EST
From: George J. Carrette <GJC@MIT-MC>
The problem was that (EQUAL "foo" "FOO") used to be T, but now is NIL,
and all the hardware databases had chip and signal names in both
upper and lowercase, depending on what the user first typed in.
It sounds like you should fix the root problem instead of this kind of
workaround. Another alternative would be to implement
CASE-INSENSITIVE-EQUAL-HASH-TABLEs, where the :test is
CASE-INSENSITIVE-EQUAL or somesuch.
So from practical experience I can definitely put in a vote for
having :TEST 'EQUALP in hash tables.
That's not to say I think equalp hash tables are a bad idea. I'm not
sure if they are good or bad. I fear the efficiency penalty of
traversing every array it finds. Your message is clearly a request for
equal-like hash table that ignore case (or maybe you should change your
hardware database (or make your program always STRING-UPCASE)).
Also keep in mind that it is relatively easy for flavor-based
implementations to "just go off and add" more types of hash tables. The
expsnse-to-implement::usefulness ratio may be too high for other
architectures/systems.
∂09-May-85 0911 FAHLMAN@CMU-CS-C.ARPA Fahlman's comments
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 May 85 09:11:36 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 9 May 85 11:36:37-EDT
Date: Thu, 9 May 1985 10:56 EDT
Message-ID: <FAHLMAN.12109643052.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA, squires@USC-ISI.ARPA
Subject: Fahlman's comments
In-reply-to: Msg of 9 May 1985 01:46-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
Ah, OK, I totally misunderstood what you were suggesting. Never mind.
Certainly if we have a public validation suite that covers everything we
want to test, and a secret set of variations on this to keep people
honest, that is the best of all possible worlds. And given that, the
machinery that you propose sounds reasonable to me.
The other manufacturers may not be enthusiastic about having Lucid be
the tester, but presumably DOD has the right to designate anyone they
want (subject, perhaps, to competitive bidding requirements) as the
validator of Lisps for government work. We still might be able to get
other companies to contribute code for the public test suite, but that
can be treated as optional.
If it looks like this plan is going to fly, I'll coordiante any work we
do in writing public-domain validation stuff with RPG so as to minimize
duplicated effort and fill in any holes as quickly as possible.
-- Scott
∂09-May-85 0929 GRISS%hp-hulk.csnet@csnet-relay.arpa Re: PARSE-BODY
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 9 May 85 09:29:06 PDT
Received: from hplabs by csnet-relay.csnet id ab22357; 9 May 85 12:26 EDT
Received: by HP-VENUS id AA25414; Thu, 9 May 85 05:55:47 pdt
Message-Id: <8505091255.AA25414@HP-VENUS>
Date: Thu 9 May 85 05:55:37-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Re: PARSE-BODY
To: JLW
Cc: common-lisp@su-ai.ARPA, GRISS@hplabs.CSNET
In-Reply-To: Message from "Jon White <JLW@SU-AI@HP-VENUS>" of Wed 8 May 85 08:35:00-PDT
Source-Info: From (or Sender) name not authenticated.
Apropos Yellow PAges. Is anything happening to the Yellow pages?
Is there a set of publically available and documented files, yet?
Martin Griss
-------
∂09-May-85 1103 RPG Comments on ...
To: quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA,
squires@USC-ISI.ARPA
I believe that the tricky and essential part of this scheme is that Lucid
(or whoever helpd with validation later on) does not actually do
validation, but they contribute evidence that is used by the validation
group itself. Second, the testing group probably has to have their Lisp
validated extra carefully, and with probably a more detailed and lengthy
technique so as to be above reproach. What the testing group produces must
be a report (full of facts like: passed the lambda-list tests, except for
the one where you SETQ the &rest argument during the optional defaulting
process) that is rebuttable and non-binding on the tested Lisp. It will be
a judgement call for someone to decide what the evidence means.
I believe that once the procedure is set up with one group doing the
work for a while, the job could rotate among the various groups
willing to do it. Also, to be quite honest, I would prefer to see the
group most likely to have (and want to have) the most rigorously
tested and complete Common Lisp be the first group to do the work.
If we don't do something like this, then we'll have to set up a separate
group at a neutral place, like ISI, and I'm simply not sure that we can
find people who would want to do that sort of work conscientiously in such
a setting. The only reason to try something like this is to find a way
for the competent people to do the job.
-rpg-
∂09-May-85 2101 FAHLMAN@CMU-CS-C.ARPA PARSE-BODY
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 May 85 21:01:48 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 10 May 85 00:01:24-EDT
Date: Fri, 10 May 1985 00:01 EDT
Message-ID: <FAHLMAN.12109786018.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Martin <GRISS%hplabs.csnet@CSNET-RELAY.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: PARSE-BODY
In-reply-to: Msg of 9 May 1985 08:55-EDT from Martin <GRISS%hplabs.csnet at csnet-relay.arpa>
We now have a small collection of public-domain programs in Common
Lisp, with documentation, for our local users at CMU. Many of these
things depend on features only present in the Perq and the Accent
operating system, though in many of those the dependencies are minor and
easily worked around. Some things are fully portable Common Lisp. A
couple of biggies (OPS5, a portable Flavors implementation, a drawing
program, and a Lisp-based shell for Spice) will be in there soon, but
are not there now.
Right now this stuff lives on CMU-CS-SPICE in /usr/spice/library/lisp.
Since anonymous FTP doesn't work on this machine, I'll try to copy this
stuff over to CMU-CS-C sometime soon, and will let people know when this
is done.
This is just a start, of course. Once we have enough things to justify
the split, I'll create separate directories for truly portable things
and those that depend on some aspect of Perq/Accent. If anyone has any
portable code to contribute, feel free to send it to me, but only if it
is public domain or if you can grant us the rights to pass this code out
to anyone who wants it.
-- Scott
∂09-May-85 2254 KMP@SCRC-STONY-BROOK.ARPA Macros -> declarations
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 May 85 22:54:25 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 234166; Fri 10-May-85 01:50:12-EDT
Date: Fri, 10 May 85 01:51 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Macros -> declarations
To: RWK@SCRC-YUKON.ARPA, Fahlman@CMU-CS-C.ARPA
cc: KMP@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <850508115301.3.RWK@CROW.SCRC.Symbolics.COM>
Message-ID: <850510015144.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Wed, 8 May 85 11:53 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Date: Tue, 7 May 1985 22:50 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Is there any hope that we can all agree on flushing macro -> declaration
expansion and replacing it with something like Skef's "declaration
macro" proposal? You state that this is the minimum acceptable position
(minimun acceptable amount of hair, I guess), and for me it's about the
maximum acceptable position. It would seem to cover about 99% of the
cases where people claim that they need the macro expansion.
Might I suggest another proposal that I think adds less complexity
for the same gain (for either side of the issue)?
Instead of DECLARE forms being allowed to be macros, why not allow the
forms INSIDE declare forms be macros? Using macros rather than
"declaration macros" lets you then use macrolet, and avoids the need for
any new "DEFDECLARE" special forms to document or implement.
No, this is too confusing. What about things like STRING which are already functions?
Do we propose to have macro syntax available in a context where function syntax is not?
I think that would be very confusing. Also, what if someone did
(DEFMACRO TYPE (X) `(PRINT ,X))
and then someone else did (DECLARE (TYPE LIST FOO)). You wouldn't want to tell people
that the possible declaration names (which are all really good names) weren't available
to them for definition as names for macros (but -were- available to them as function
names)... would you?
This doesn't quite cover the bases, though, unless we also deal with
expanding into multiple declarations [i.e. (REGISTER X) ->
(SPECIAL X) (FIXNUM X)].
I'll propose two ways to deal with that.
Skef's declaration macros covered this case by making them always return a list of
declarations. (This also allows one to conveniently return no declarations, which is
good since if (REGISTER X) didn't want to expand into any declarations it would
otherwise be stuck expanding into NIL implying (DECLARE NIL) which may be ill-formed
for all I know... or (SPECIAL) implying (DECLARE (SPECIAL)) which is semantically silly.)
1) Allow (DECLARE (FOO X) ((SPECIAL X) (FIXNUM X))) to mean the
same as (DECLARE (FOO X) (SPECIAL X) (FIXNUM X))
2) Allow (DECLARE (FOO X) (DECLARE (SPECIAL X) (FIXNUM X))). I.e.
Allow DECLARE as a declaration containing declarations.
Yuck.
On the other hand, I'm really bothered by the fact that one can write:
(DEFMACRO DECLARE-FOO (&REST X) `(DECLARE (FOO ,@X)))
and use (DECLARE-FOO ...) at toplevel but not inside a DEFUN. I think people
will find this an ugly inconsistency.
I am also bothered by the idea of checking explicitly for DECLARE because
it means that the thing would not really be an operator at all. It would
essentially be just a part of the syntax of some other form (eg, DEFUN or
LAMBDA) -- yet another odd kind of keyword (like OTHERWISE in SELECTQ).
And when everything is said and done, the only thing we're trying to avoid
is occasionally having to change:
(DEFMACRO DEFFOO (NAME BVL &BODY FORMS)
`(DEFUN ,(FOOIFY NAME) BVL ,@FORMS))
Oops, no that's not one of the one that has to change. Lemme see. It's gotta
be more complicated than that before any of this matters. Ah yes, I wrote
something like this just the other day:
(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS)
`(DEFMACRO ,NAME ,BVL
(MAKE-MY-ENCAPSULATION (PROGN ,@FORMS))))
must be rewritten as
(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS &ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (BODY DECLARATIONS DOCUMENTATION)
(PARSE-BODY FORMS)
`(DEFMACRO ,NAME ,BVL
,@DECLARATIONS ,DOCUMENTATION
(MAKE-MY-ENCAPSULATION (PROGN ,@BODY)))))
I just don't see this as a big deal.
Since it is so idiomatic, though, how about if &BODY did the declaration
parsing if you gave it a list of vars instead of a symbol var. Eg,
(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY (BODY DECLS DOC))
`(DEFMACRO ,NAME ,BVL
,@DECLS ,DOC
(MAKE-MY-ENCAPSULATION (PROGN ,@BODY))))
could be defined to mean the same as what I had just written. Or maybe
(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY BODY DECLS DOC)
...)
if you thionk the DECLS and DOC look too much like initializations and
present-p checks the other way. This latter syntax means you could have
defaults for these. Eg,
(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY (BODY '(...default body...))
(DECLS '((DECLARE (SPECIAL *FOO*))))
(DOC "a macro"))
...)
I believe that attacking the problem of DECLARE at the level people have been
attacking it gives up programmer flexibility to no good end (not to mention
introducing an incompatible change to the language semantics). A change
like these syntax extensions to DEFMACRO that I've been speaking about would
make life easy for the macro writer without giving up the macro-writing
freedoms I was originally supporting.
Thoughts?
∂09-May-85 2319 JLW READ-AN-DO-FILE-ATTRIBUTES
To: Fahlman@CMU-CS-C.ARPA
CC: common-lisp@SU-AI.ARPA
Yes, by "system-supplied", I was proposing this for white pages level on
the next go-around (hopefully, for yellow pages level during the interim --
expecting that interim not to be longer than 2 years).
But I didn'nt mean to imply the Lispm convention of lines with ;;; -*-
when saying "attributes"; I mean the generalized notion of whatever
the agreed-upon convention will be. This means that merely having
the 7-extremely-randoms in a lisp-like syntax near the beginning of
the file would be fine.
Moon is disinclined to go for another convention (i.e. something other
than the ;;; -*-), and one can sympathize with him, given the investment
of time etc that Symbolics has in it. But I don't think it would be so
hard to spec out a lisp-syntax proposal, especially if there were a means
of doing a "limited" READ (i.e., a READ that doesn't swallow more than,
say, 1024 characters.) It's not just a love of lisp syntax that brings
this matter up, but rather the difficlty of extending the ;;;-*- notation
to meet the increasing number of contextual needs.
-- JonL --
∂09-May-85 2356 JLW EQUALP hash tables (and more ...)
To: tim@MIT-MC.ARPA
CC: common-lisp@SU-AI.ARPA
Not too long ago, some of the LOOPS people at Xerox PARC needed a more
generalized form of hashing; the solution was to admit two more "properties"
of hashtables -- the "equivalenceing" function, and the "numericalizing"
function. Both of these are fully general arguments -- the user may supply
any reasonable function there -- and I don't see why such an extended definition
hasn't been accepted into CL; can anyone remember a reason for the restriction
to such a limited set? [current Interlisp-D release documents changes made
to hashing almost a year ago -- this loops-inspired extension was done only
at the end of 1984, and wasn't even fully integrated into the system by the
time I left Xerox in January 1985].
For "equivalence" function, the user may supply #'eq, #'string=, or even
something random like #'=-mod-5; the "numericalizing" function is simply
how to reduce a general s-expression into a reaonable sized fixnum; for EQ
type tables, this is usually something like MacLisp's MAKNUM (Interlisp's LOC),
and for EQUAL type tables it is usually SXHASH.
One very interesting point to note is that the CLM doesn't require that EQ
type tables actually use the pointer address (ie. numericalizing by MAKNUM);
apparently in an effort to maintain generality and portability, the only
specification for such tables is that the equivalencing test be EQ. I and
several of my colleagues "believe" that everyone thinks hashing on EQ means
using the pointer address, rather than the sxhash, as the numerical start --
but nothing in the CLM would prevent an implementation from using sxhash
instead. And indeed, the only way one would ever notice the difference
(apart from an unreasonably slow implementation of SXHASH!), is that
using MAKNUM would insulate against re-orderings of the "chains" inside
the table [I'm assuming everyone knows the problem with using sxhash
for the numericalizing -- that updates to a hashed structure will change
its sxhash value, and thereby cause it to be in a differnt chain in
the hash table.]
-- JonL --
∂10-May-85 0017 JLW Y.A.R.I.M.: Macros inside DECLARE?
To: rwk@SCRC-STONY-BROOK.ARPA
CC: common-lisp@SU-AI.ARPA
In-reply-to: your message of 8-May-85 11:53 EDT
As far as I'm concerned, your attempt to unify source-level transformations
under the existing DEFMACRO is the best thing to come out of all this
discussion. No more DEFMUMBLEs where DEFMUMBLE is
YetAnotherRedundantImitationofMacros!
I feel that this is more important than the issues of whether macros may
produce declares, or whether declare macroexpands its innards.
The comment above is also a vote against "lambda macros" -- they provide
absolutely no functionality beyond that capable by ordinary macros, and
give only marginally better error checking.
-- JonL --
∂10-May-85 0146 hoey@nrl-aic Re: EQUALP hash tables (and more ...)
Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 10 May 85 01:46:39 PDT
Date: 10 May 1985 03:54:51 EDT (Fri)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: EQUALP hash tables (and more ...)
To: Jon White <JLW@SU-AI.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Message-Id: <484559691/hoey@nrl-aic>
Date: 09 May 85 2356 PDT
From: Jon White <JLW@SU-AI.ARPA>
... a more generalized form of hashing ... two more "properties" of
hashtables -- the "equivalenceing" function, and the "numericalizing"
function....
For "equivalence" function, the user may supply #'eq, #'string=, or
even something random like #'=-mod-5;
Bravo! If CL should have hash tables, it should have these. The
existing lack of functionality is embarrassing in an otherwise
orthogonal, extensible language.
... the "numericalizing" function is simply how to reduce a general
s-expression into a reasonable sized fixnum....
I would leave off ``reasonable sized''; certainly gethash is capable of
hashing a fixnum value to its favorite range.
I [believe] hashing on EQ means using the pointer address...
but nothing in the CLM would prevent an implementation from using sxhash
instead.
Two problems with this. First, as you note, the key could get
modified. I'm not sure you noticed, but this means that in order for
GETHASH to fail, it would have to examine the whole table for modified
structures. Second, I think SXHASH might not terminate on circular
structures, though this caveat is not in the manual (and it, or its
denial, should be).
Dan
∂10-May-85 0906 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 May 85 09:06:19 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 10 May 85 11:35:56-EDT
Date: Fri, 10 May 1985 10:18 EDT
Message-ID: <FAHLMAN.12109898307.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 10 May 1985 01:51-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
I agree with KMP's critique of RWK's proposal to just use normal macros
inside the declaration forms. Too many problems.
As for KMP's comments...
On the other hand, I'm really bothered by the fact that one can write:
(DEFMACRO DECLARE-FOO (&REST X) `(DECLARE (FOO ,@X)))
and use (DECLARE-FOO ...) at toplevel but not inside a DEFUN. I think people
will find this an ugly inconsistency.
But you CAN'T use DECLARE-FOO at top-level, since the DECLARE form
produced will not be legal there. In general, macros only work in place
of forms that you are going to evaluate. In quoted contexts, or other
non-evaluated places like arglists, a macro would never expand. DECLARE
is one of those, since you never evaluate the DECLARE, but just look at
it while deciding how to set up the arguments. The ugly inconsistency
here is allowing macros in this place.
I am also bothered by the idea of checking explicitly for DECLARE because
it means that the thing would not really be an operator at all. It would
essentially be just a part of the syntax of some other form (eg, DEFUN or
LAMBDA) -- yet another odd kind of keyword (like OTHERWISE in SELECTQ).
That's right, DECLARE is not an opertor in Common Lisp, just a piece of
syntax that happens to take the form of an operator. The form is
probably a hold-over from Maclisp, where DECLARE was an operator. If we
had chosen a different syntax for this, such as always having the first
list of the body be a declaration without any DECLARE marker in front of
it, or hiding the declarations in the arglist after an &declare marker,
we would not have made the mistake of treating this as a funny kind of
operator when it's really structural.
(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS)
`(DEFMACRO ,NAME ,BVL
(MAKE-MY-ENCAPSULATION (PROGN ,@FORMS))))
must be rewritten as
(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS &ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (BODY DECLARATIONS DOCUMENTATION)
(PARSE-BODY FORMS)
`(DEFMACRO ,NAME ,BVL
,@DECLARATIONS ,DOCUMENTATION
(MAKE-MY-ENCAPSULATION (PROGN ,@BODY)))))
I just don't see this as a big deal.
It may not be a big deal, but you DID get it wrong. Parse-Body has to
receive the appropriate ENV as an argument in order to do its work,
unless your version of Parse-Body is somehow getting this as a special.
That, basically, is the mistake that people keep making.
Well, it looks like we're going to lose this battle. Too many people on
this list are fascinated by the alleged flexibility that the macro ->
declaration misfeature gives them, and too few are bothered by the
errors, confusion, and inefficiency that this causes. Since the
misfeature is already in the manual, it would require a clear consensus
to remove it, and I don't see that emerging.
The fallback position is to add a reasonable PARSE-BODY form to the
language, with a required environment argument as well as the forms
argument. We should probably do that in any event, since each and every
implementation seems to have invented this and few people can write a
correct macro without this. The manual will need to be extended, in the
section on Macros, I guess, to explain what this is about and give an
example or two.
I am also very interested in KMP's suggestion for an extenstion to the
&body syntax, but need to study this a bit to make sure that there are
not hidden problems. The big advantage of this, of course, is that it
allows the casual macro-writer to avoid dealing explicitly with
environments and hairy M-V uses of Parse-body for most simple things. I
grant that people who can't hack these things shouldn't be writing
macros, but they will be, and life will be easier all around if we can
make this process less error-prone.
-- Scott
∂10-May-85 1057 REM@IMSSS Instead of read macros, how about one reserved-word for process-time macro?
Received: from IMSSS by SU-AI with PUP; 10-May-85 10:57 PDT
Date: 10 May 1985 1058-PDT
From: Rem@IMSSS
Subject: Instead of read macros, how about one reserved-word for process-time macro?
To: COMMON-LISP@SU-AI
Here's an idea I used here as an alternative to splicing macros and other
MacLISP grunge which weren't available here, and which might in CL be a general
solution to macro->declare, argument-list macros, etc.
Have one reserved word, which in the CAR position of any form, even an
inner form, causes the CADR to be the name of a macro and the CDDR to be
a form to be passed to that macro. The result from that macro is then the
effective form to be processed instead of the original form containing the
reserved word. For example, if ! is the reserved word, and FOO is a macro,
then (A B ! FOO X Y Z) means (A B . q) WHERE q is the result of applying
FOO to the s-expression (X Y Z). For example, if FOO is a macro that
expands into the arglist (VAL1 VAL2 TMP) then (DEFUN BAR (!FOO) ...)
is effectively (DEFUN BAR (VAL1 VAL2 TMP) ...). If you want to patch
things together, use ! before CONS or APPEND, for example if FOO2 is
a macro that expands into another arglist (PTR1 PTR2) then you can get
all five args by saying (DEFUN BAR (! APPEND (! FOO) (! FOO2)) ...).
I'm a bit sloppy because this is just an idea. Should we use recursive
evaluation when passing arguments to macros or functions named after !,
or should we use EVALQUOTE conventions where args are implicitly quoted?
You can of course suppress evaluation by ' or increase evaluation by
doing (! EVAL <form>) so either way you get full flexibility. Of course
the context of the macro-expansion should be whatever context would be
doing the normal processing of the data. Note that even user data could
use this convention if the particular program doing the processing were
(advertised as) respecting this data-macro convention. Initially only a
few system utilities would respect this convention, such as the compiler
and interpretor when the data-macro appears in certain places in forms
to be compiled or evaluated, but later additional programs could install
the convention and start to advertise it. (Imagine having random data
fed into some random program that happens to respect the convention, with
that data having the ability to perform arbitrary processing before
passing the effective data to the program! Sort of like actors/objects!)
-------
∂10-May-85 1139 BSG@SCRC-STONY-BROOK.ARPA Y.A.R.I.M.: Macros inside DECLARE?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 May 85 11:38:52 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 234523; Fri 10-May-85 14:34:23-EDT
Date: Fri, 10 May 85 14:39 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Y.A.R.I.M.: Macros inside DECLARE?
To: JLW@SU-AI.ARPA, rwk@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 10 May 85 03:17-EDT from Jon White <JLW@SU-AI.ARPA>
Message-ID: <850510143907.6.BSG@CONCORD.SCRC.Symbolics.COM>
Date: 10 May 85 0017 PDT
From: Jon White <JLW@SU-AI.ARPA>
In-reply-to: your message of 8-May-85 11:53 EDT
As far as I'm concerned, your attempt to unify source-level transformations
under the existing DEFMACRO is the best thing to come out of all this
discussion. No more DEFMUMBLEs where DEFMUMBLE is
YetAnotherRedundantImitationofMacros!
I feel that this is more important than the issues of whether macros may
produce declares, or whether declare macroexpands its innards.
The comment above is also a vote against "lambda macros" -- they provide
absolutely no functionality beyond that capable by ordinary macros, and
give only marginally better error checking.
-- JonL --
Do I read you right, that what you are suggesting is that
I say (defmacro adbmal (x) `(lambda . (cdr ,x)))
and I could then say
(funcall foo #'(adbmal (y) (+ y 3))
? That's clearly right.
∂10-May-85 1239 BSG@SCRC-STONY-BROOK.ARPA Macros -> declarations
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 May 85 12:39:02 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 234581; Fri 10-May-85 15:34:38-EDT
Date: Fri, 10 May 85 15:39 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Macros -> declarations
To: KMP@SCRC-STONY-BROOK.ARPA, RWK@SCRC-YUKON.ARPA,
Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850510015144.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <850510153924.2.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Fri, 10 May 85 01:51 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
No, this is too confusing. What about things like STRING which are already functions?
Do we propose to have macro syntax available in a context where function syntax is not?
I think that would be very confusing. Also, what if someone did
(DEFMACRO TYPE (X) `(PRINT ,X))
and then someone else did (DECLARE (TYPE LIST FOO)). You wouldn't want to tell people
that the possible declaration names (which are all really good names) weren't available
to them for definition as names for macros (but -were- available to them as function
names)... would you?
Damn! Just when I was beginning to like this! How about, for a really off-the-wall suggestion,
a "macroification context", defined by each macro by the &EXPANDWHEN-CONTEXT notkeyword, and
whose default is (:EVAL :COMPILE) (choose any names you like)
(defmacro push (x y &expandwhen-context (:eval :compile)) ..etc.)
means that evaluation and compilation (the only kind valid today) are the contexts in which
this macro will be recognized. (I can see several implementation possibilities.)
This allows extension to :declaration, :functional-form (lambda macro) :lap-code and
n other non-intrusive, compatible possibilities.
Thus,
(defmacro register (x &EXPANDWHEN-CONTEXT :declare) `(fixnum ,(cdr x)))
∂10-May-85 2005 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 May 85 20:05:34 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 10 May 85 22:35:40-EDT
Date: Fri, 10 May 1985 22:04 EDT
Message-ID: <FAHLMAN.12110026915.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "Bernard S. Greenberg" <BSG@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 10 May 1985 15:39-EDT from Bernard S. Greenberg <BSG at SCRC-STONY-BROOK.ARPA>
You forgot to put in the :-) glyph. Without it, someone might thing you
are serious.
-- Scott
∂11-May-85 0635 FAHLMAN@CMU-CS-C.ARPA :-(
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 May 85 06:35:36 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 11 May 85 09:35:44-EDT
Date: Sat, 11 May 1985 09:35 EDT
Message-ID: <FAHLMAN.12110152717.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: :-(
Upon reflection, I shouldn't have been so flippant in dismissing BSG's
suggestion about macro-expansion environments, and I apologize to him.
I assume that his suggestion was serious, and poking fun at suggestions
that we disagree with is obviously not the best way to promote the free
flow of ideas. It has been a long week, and I was feeling irritable.
I think that this suggestion is a step in the wrong direction. We want
to make the whole issue of macros expanding in funny places less
confusing, not more so, and a multiple name space mechansism so that
macros in various places can have the same name doesn't look to me like
a good idea.
-- Scott
∂11-May-85 0759 FAHLMAN@CMU-CS-C.ARPA EQUALP hash tables (and more ...)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 May 85 07:59:16 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 11 May 85 10:59:21-EDT
Date: Sat, 11 May 1985 10:59 EDT
Message-ID: <FAHLMAN.12110167939.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Jon White <JLW@SU-AI.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: EQUALP hash tables (and more ...)
In-reply-to: Msg of 10 May 1985 02:56-EDT from Jon White <JLW at SU-AI.ARPA>
The Interlisp-like extension to hash tables that JONL proposes sounds
like a pretty good one to me: allow users to specify their own test
functions, but if they choose anything other than a small set of
"built-in" tests, they have to supply the appropriate numericalizing
function as well. I'm not sure what the new keyword to make-hash-table
would be. :numericalize doesn't do much for me.
This is a compatible extension, as long as we allow the user not to
supply the numericalizer if the test is one of EQ, EQL, or EQUAL (and
maybe we add EQUALP). For EQ, at least, the numericalizer has to be
built in, because we really can't put anything like MAKNUM in the
portable language.
A few other things might be required to round this out. One is a
keyword that says whether the table has to be rehashed after a GC, as
most implementations now do for EQ hashtables. This switch would be
ignored in implementations that do not move things during a GC. We also
probably want to supply the user with a manual REHASH function that takes a
whole hashtable and rehashes it. For modifying individual keys, we just
have to make clear to the users that they had better remove the item,
alter it, and then put it back.
I'm not sure if we want to make so large an extension to hash tables,
but if we do, this is a compatible way of doing it.
-- Scott
∂11-May-85 1229 WHOLEY@CMU-CS-C.ARPA EQUALP hash tables (and more ...)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 May 85 12:29:13 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Sat 11 May 85 15:29:18-EDT
Date: Sat, 11 May 1985 15:29 EDT
Message-ID: <WHOLEY.12110217078.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Common-Lisp@SU-AI.ARPA
Subject: EQUALP hash tables (and more ...)
In-reply-to: Msg of 11 May 1985 10:59-EDT from Scott E. Fahlman <Fahlman>
I think a user-extensible hash table mechanism would be a win, and would be
easily implementable even in our non-flavorized system (surprise, surprise).
I have a few comments, though:
1. I don't think it's possible to let users write some form of hashing function
that generates = numbers for EQ objects. There might be an arbitrarily long
time between computing the hash number and using it as an index into a vector,
in which countless objects may be transported or garbage collected. This, of
course, entirely ignores the ugly mechanism that necessitates rehashing the
hash tables at the right time. I would suggest that any hashing facility
involving EQ or EQL for some subset of Lisp objects be left to the system. I
really don't think much functionality is lost this way, although I know it's
very easy to dream up examples which "need" such a feature.
2. The user-supplied hashing function (why not call it :hash instead of
:equivalencing?) will probably want to avoid running into bignum arithmetic and
so forth. The manual should at least mention this danger when describing this
feature.
3. Some implementations may have tense routines for computing a hash code for
certain objects. String hashing is microcoded on the Perq, and assembly-coded
on other Spice Lisp-derived systems, for example. A user can get to this
particular routine via SXHASH, but that might not be the case for other hash
functions. Should all specialized, system-supplied, hashing functions be
implementation specific, and documented in the appropriate places? I guess
that would work.
4. Regarding SXHASH on circular structures: Might there be optional arguments
to SXHASH to restrict the "length" and "depth" it will descend into an object?
These would default to some "reasonable" implementation-dependent values. One
Spice Lisp application (a spelling checker that lives inside the editor) dives
straight into the microcode to compute the hash value of a substring. This
extension to SXHASH would eliminate non-portabilities like that.
--Skef
∂11-May-85 1404 RWK@SCRC-STONY-BROOK.ARPA Macros -> declarations
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 May 85 14:03:43 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 234939; Sat 11-May-85 16:59:15-EDT
Date: Sat, 11 May 85 17:03 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Macros -> declarations
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
cc: Fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <850510015144.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <850511170339.8.RWK@CROW.SCRC.Symbolics.COM>
Date: Fri, 10 May 85 01:51 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Date: Wed, 8 May 85 11:53 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Instead of DECLARE forms being allowed to be macros, why not allow the
forms INSIDE declare forms be macros? Using macros rather than
"declaration macros" lets you then use macrolet, and avoids the need for
any new "DEFDECLARE" special forms to document or implement.
No, this is too confusing. What about things like STRING which are already functions?
Do we propose to have macro syntax available in a context where function syntax is not?
I think that would be very confusing.
It certainly would be confusing to define a declaration named STRING,
since there's already a function of that name. In our system, you'd
get redefinition warnings. Why not call it STRING-DECL? How is this
any more confusing than any other naming conflict?
Also, what if someone did
(DEFMACRO TYPE (X) `(PRINT ,X))
and then someone else did (DECLARE (TYPE LIST FOO)). You wouldn't want to tell people
that the possible declaration names (which are all really good names) weren't available
to them for definition as names for macros (but -were- available to them as function
names)... would you?
No, of course not. I see no reason why DECLARE should macroexpand things
it already understands. To do so would be to allow gratiutous confusion,
such as this.
1) Allow (DECLARE (FOO X) ((SPECIAL X) (FIXNUM X))) to mean the
same as (DECLARE (FOO X) (SPECIAL X) (FIXNUM X))
2) Allow (DECLARE (FOO X) (DECLARE (SPECIAL X) (FIXNUM X))). I.e.
Allow DECLARE as a declaration containing declarations.
Yuck.
Hey, remember that this is the expanded output of a macro, not
something that you write in your code. I think the macro definition
ends up looking pretty obvious, and besides, the compiler is likely
to give you a useful error message if you put one of these macros
in an inappropriate place.
(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS)
`(DEFMACRO ,NAME ,BVL
(MAKE-MY-ENCAPSULATION (PROGN ,@FORMS))))
must be rewritten as
(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS &ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (BODY DECLARATIONS DOCUMENTATION)
(PARSE-BODY FORMS)
`(DEFMACRO ,NAME ,BVL
,@DECLARATIONS ,DOCUMENTATION
(MAKE-MY-ENCAPSULATION (PROGN ,@BODY)))))
I just don't see this as a big deal.
I don't, either, since you need that, regardless of whether
or not macros can expand into DECLARE's. However, thinking
of humans, I have to say that I don't like macros expanding
into entire DECLARE forms because it gets in the way of my
adding my own declaration, and because *I* might not recognize
something as a declaration. I'm not too worried about it
being "too hard" for programs to handle.
I believe that DECLARE is already structural, rather than
an operator, and that allowing macros to expand into it
merely confuses that issue.
The other reason I proposed making them macros is so that
MACROLET could be used. Most of the uses I can think of
would be to allow declarations inside of calls to macros,
where MACROLET would be just the right thing to define
any declarations.
Since it is so idiomatic, though, how about if &BODY did the declaration
parsing if you gave it a list of vars instead of a symbol var. Eg,
(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY (BODY DECLS DOC))
`(DEFMACRO ,NAME ,BVL
,@DECLS ,DOC
(MAKE-MY-ENCAPSULATION (PROGN ,@BODY))))
This (and its varients I omit for brevity) is a very interesting
suggestion, and is worth of discussion independently of of the
declaration/macro issue.
∂11-May-85 2300 TIM@MIT-MC Macros -> declarations
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 11 May 85 22:59:24 PDT
Date: Sun, 12 May 85 01:58:19 EST
From: Tim McNerney <TIM@MIT-MC>
Subject: Macros -> declarations
To: common-lisp@SU-AI
Message-ID: <[MIT-MC].498921.850512.TIM>
Date: Fri, 10 May 85 01:51 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Date: Wed, 8 May 85 11:53 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Instead of DECLARE forms being allowed to be macros, why not allow
the forms INSIDE declare forms be macros? Using macros rather than
"declaration macros" lets you then use macrolet, and avoids the need
for any new "DEFDECLARE" special forms to document or implement.
No, this is too confusing. What about things like STRING which are
already functions? Do we propose to have macro syntax available in a
context where function syntax is not? I think that would be very
confusing.
IFF we have to flush macros -> declarations, I think Kerns' user-extensible
DECLARE is the most palatable suggestion so far. Unfortunately, there are a
number of problems with allowing macros inside of DECLARE, and indeed with
nearly any user-extensible DECLARE.
Perhaps the biggest problem is that the namespace available for use as
declaration names has already been "given away." The sort naming conflict
that KMP bought up could be solved by having a declarations package which
does not use the LISP package, but CL implementations are free to use any
names not explicitly mentioned in CLTL for implementation-dependent
declarations. Thus, allowing macros inside of DECLARE could potentially
reduce the portability of code that used this proposed feature.
Whereas
(declare-private-specials) -> (declare (special *foo* *bar*))
would pose no problems with portability,
(declare (private-specials)) -> (declare (special *foo* *bar*))
might conflict with an existing PRIVATE-SPECIALS declaration specific to a
given target implementation (unless the user is allowed to override
implementation-dependent declaration names with his own, yuk!).
I vote for keeping macros -> declarations and augmenting the language
with a set a standard tools for keeping hairy macro writers out of trouble.
∂12-May-85 0550 GJC@MIT-MC hash table types
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 May 85 05:50:31 PDT
Date: Sun, 12 May 85 08:51:09 EST
From: George J. Carrette <GJC@MIT-MC>
Subject: hash table types
To: DCP@SCRC-QUABBIN
cc: TIM@MIT-MC, COMMON-LISP@SU-AI
In-reply-to: Msg of Thu 9 May 85 12:01 EDT from David C. Plummer in disguise <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MIT-MC].499100.850512.GJC>
We figured that fixing the root of the problem, the lack of canonicalization
in the hardware database would possibly cost enough time to break a production
development window and put off the introduction of a new hardware item
for a few months, with possible losses in sales of a million dollars
or more for the year. Given this sort of lossage mode one cant stress
enough the importance of having *some* way of getting compatibility
between RELEASE N and RELEASE N+1. Remember that at some time
in "zetalisp" EQUAL on type STRING meant STRING-EQUAL, which was for
better or worse case insensitive. LMI release 2 and presumably also
Symbolics release 6 does away with this. If there is nothing available
which behaves in exactly the same way as the *old* EQUAL-HASH-TABLE
then people can be screwed badly. Remember also that many ugly things
that were left in Common-Lisp from maclisp days (such as the empty
list being a SYMBOL, making the set of all lists and all symbols
have a non-null intersection) were justified soley on the basis that
there was no *automatic* way for people to detect if they were depending
on such lossage and convert their programs. To quote Dave Moon:
"Our customers just wont stand for it."
-gjc
∂12-May-85 1225 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: defconstant vs. lexical variables
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 12 May 85 12:25:23 PDT
Date: Sun, 12 May 85 15:17 EDT
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: Re: defconstant vs. lexical variables
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 6 May 85 15:40 EDT from "OLDMAN at USC-ISI"
Message-ID: <850512191735.970989@MIT-MULTICS.ARPA>
Date: 6 May 1985 15:40 edt
From: OLDMAN at USC-ISI
Subject: defconstant vs. lexical variables
Page 69 of the CLM states:
"Once a name has been declared by defconstant to be constant, any
further assignment to or binding of that special variable is an
error. ... A compiler may also choose to issue warnings about
bindings of the lexical variable of the same name."
Question: How can I make a lexical binding of the thing if it's
implicitly proclaimed special by the defconstant?
Alternate question: Why don't we have a way of declaring
something locally lexical?
--Dan Oldman {Data General}
Answer:
(defun foo (lex-x) ...)
(proclaim '(special lex-x)) ; Compiler should warn me
; when it hits this statement.
Alternate answer:
I don't know. I think we should also. Until then, one should
stick to the convention of surrounding special vars. with *'s.
This should reduce the chance of unknowingly using a var. that
has been proclaimed special.
∂12-May-85 1748 hoey@nrl-aic Re: EQUALP hash tables (and more ...)
Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 12 May 85 17:47:59 PDT
Date: 12 May 1985 19:12:56 EDT (Sun)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: EQUALP hash tables (and more ...)
To: Wholey@CMU-CS-C.ARPA, Fahlman@CMU-CS-C.ARPA, Common-Lisp@SU-AI
Message-Id: <484787577/hoey@nrl-aic>
In-Reply-To: Msg of 11 May 1985 15:29 EDT from Skef Wholey and
Msg of 11 May 1985 10:59-EDT from Scott E. Fahlman
Skef,
I was about to bring up the problem you mentioned:
``I don't think it's possible to let users write some form of hashing
function that generates = numbers for EQ objects.''
but then I noticed that the language already provides a mechanism for
writing a perfect EQ hashing function:
(DEFVAR *EQ-HASH-TABLE* (MAKE-HASH-TABLE :TEST #'EQ))
(DEFVAR *EQ-HASH-COUNTER* 0)
(DEFUN EQHASH (X)
(OR (GETHASH X *EQ-HASH-TABLE*)
(SETF (GETHASH X *EQ-HASH-TABLE*) (INCF *EQ-HASH-COUNTER*))))
It is a pity that there's no way to let the GC collect stuff out of the
*EQ-HASH-TABLE* for fear of breaking MAPHASH. Maybe there should be
some way of declaring a hash table GC-able, perhaps by declaring it
un-MAPHASH-able.
Dan
∂12-May-85 2030 FAHLMAN@CMU-CS-C.ARPA EQUALP hash tables (and more ...)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 May 85 20:30:38 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 12 May 85 23:30:34-EDT
Date: Sun, 12 May 1985 23:30 EDT
Message-ID: <FAHLMAN.12110566837.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dan Hoey <hoey@NRL-AIC.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: EQUALP hash tables (and more ...)
In-reply-to: Msg of 12 May 1985 19:12-EDT from Dan Hoey <hoey at nrl-aic.ARPA>
...
but then I noticed that the language already provides a mechanism for
writing a perfect EQ hashing function:
(DEFVAR *EQ-HASH-TABLE* (MAKE-HASH-TABLE :TEST #'EQ))
(DEFVAR *EQ-HASH-COUNTER* 0)
(DEFUN EQHASH (X)
(OR (GETHASH X *EQ-HASH-TABLE*)
(SETF (GETHASH X *EQ-HASH-TABLE*) (INCF *EQ-HASH-COUNTER*))))
So I guess the point is that given magic EQ and EQL hashtables that work
even when a GC moves things, you can use these to build a slower version
of EQ and EQL hashtables (and related thingies) that also works, without
giving the users direct access to the magic. Interesting in principle,
but not the way you'd want to do anything real.
By allowing the user to specify at hashtable creation time whether his
hashing function at some level makes use of something that amounts to an
address pointer (and which will therefore need to be fixed after a
copying GC mangles things), we allow the user to win without having to
make hashtable references in the course of his comparison.
-- Scott
∂13-May-85 0905 JLW YARIM and the adbmal example
To: bsg@SCRC-STONY-BROOK.ARPA
CC: common-lisp@SU-AI.ARPA
Re: your message of 10-May-85 14:39 EDT
Not only is your adbmal example "right", but the following would have to
work too
(defmacro mumble (x) `(lambda (,x) (list ,x)))
(defun foo () ((mumble z) (mumble z)))
I just tried this out in pdp10 maclisp, and it still sort of works [I
remember putting this hac in about 1979 or 1980, and it wasn`t all
that well received even back then].
Incidentally, I did take your suggestion for macro-expansion contexts
seriously. Not that I approve of going al the way for it, but you do
bring into focus the fact that several different kinds of processing
are going on during interpretations -- not just EVAL alone, but there
is FUNVAL (if you will) to fetch the function part, there is DODECLS
to add to a declarations database [Maclisp had a functional counterpart
to DECLARE, which is why macroexpansion seemed like such a natural idea
there], and there is lambda-list parsing. I'd prefer to see a uniform
meta-expansion syntax -- such as defmacro -- but we may have to consider
context as per your suggestion.
-- JonL --
∂13-May-85 0919 BSG@SCRC-STONY-BROOK.ARPA :-(
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 May 85 09:12:30 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 235635; Mon 13-May-85 12:07:49-EDT
Date: Mon, 13 May 85 12:13 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: :-(
To: Fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12110152717.BABYL@CMU-CS-C.ARPA>
Message-ID: <850513121344.4.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Sat, 11 May 1985 09:35 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Upon reflection, I shouldn't have been so flippant in dismissing BSG's
suggestion about macro-expansion environments, and I apologize to him.
Thankyou. I thought your assessment was in fact unduly harsh. The
criteria for judging this kind of suggestion should include, "Does it
solve the problem?" "Does it create new problems?" "Does it bother
things other than the thing it was designed to address?" "Given that it
addresses some hairy need, will you have to deal with it unless you have
that hairy need?" "Is it consistent in design and philosophy with the
rest of the language?" "Is it straightforward to explain?" "Is
efficient implementation obvious?" I think that the general idea
of my suggestion meets these (admittedly self-supplied) criteria.
I assume that his suggestion was serious, and poking fun at suggestions
that we disagree with is obviously not the best way to promote the free
flow of ideas. It has been a long week, and I was feeling irritable.
Thankyou. I hope you feel better.
I think that this suggestion is a step in the wrong direction. We want
to make the whole issue of macros expanding in funny places less
confusing, not more so, and a multiple name space mechansism so that
macros in various places can have the same name doesn't look to me like
a good idea.
(what follows is sort of rambling...)
Any better than the "declaration 'functions'" (like STRING in the
preceding conversation) having the same name as a real function? Why
isn't the set of those things extensible? Remember in MacLisp they
actually WERE functions? I suppose macros there worked! I wonder if
anyone actually ever exploited that!
But now we are above that, and we have asserted that the declaration
namespace is in fact divorced from the function namespace. There
already -is- this multiple namespace. As there should be. Why isn't a
macro paradigm within that namespace reasonable? OK, don't use
defmacro, say
(putprop 'my-decl #'my-decl-expander :declaration-macro) for all I care,
if my syntax is too bizarre. It seems as though it's that very capability
that you don't like.
I would like to dredge up an elegant feature of LAP (remember those?) on
Multics, which, if it encountered a symbol marked as a Lisp Macro
name-symbol, as the CAR of an instruction specification, it would apply
the macro-function to the instruction specification, and assemble the
returned list of instructions in place.
This is a typical, potent, and elegant use of "the Lisp Macro concept"
to extend operator sets embedded in the Lisp Language. -Surely-, if I
had thought along these lines back then, we would have some different
kind or option of DEFMACRO (which didn't even exist per se) for defining
LAP macros in this way.
DEFMACRO provides three things for you:
1) A way to define a -LISP FUNCTION- to be called by the evaluator
and compiler at certain highly specific times and contexts.
2) A way to define a Lisp function of one argument which has
built-in syntactic shorthands for destructuring and structure-verifying
that argument.
3) A -conceptual- ability, a paradigm, for extension of the language via
transformation of code fragments.
2 & 3, esp. 3, are obviously, by the cited examples, useful in a wide,
extensible variety of contexts other than "evaluation/compilation of
Lisp forms". Clearly, I can put in replacements for (1) (e.g., DEFLAPMACRO)
all I want, in any program I want (does this invoke your objection of
"macros expanding in funny places?"). There is nothing in the language
to prevent me, or even discourage me from doing this. In fact,
I think it is something to encourage.
Having said that, why is the notion of the Language providing hooks of
-some kind- for extensibility via transformation (a euphemism, if you like),
at other points where the symbol CAR of a form is significant (e.g., LAMBDA,
declarations, type specs.....) not reasonable?
∂13-May-85 0930 BSG@SCRC-STONY-BROOK.ARPA YARIM and the adbmal example
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 May 85 09:21:11 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 235644; Mon 13-May-85 12:16:32-EDT
Date: Mon, 13 May 85 12:22 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: YARIM and the adbmal example
To: JLW@SU-AI.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 13 May 85 12:05-EDT from Jon White <JLW@SU-AI.ARPA>
Message-ID: <850513122226.5.BSG@CONCORD.SCRC.Symbolics.COM>
Date: 13 May 85 0905 PDT
From: Jon White <JLW@SU-AI.ARPA>
Re: your message of 10-May-85 14:39 EDT
Not only is your adbmal example "right", but the following would have to
work too
(defmacro mumble (x) `(lambda (,x) (list ,x)))
(defun foo () ((mumble z) (mumble z)))
I just tried this out in pdp10 maclisp, and it still sort of works [I
remember putting this hac in about 1979 or 1980, and it wasn`t all
that well received even back then].
Incidentally, I did take your suggestion for macro-expansion contexts
seriously. Not that I approve of going al the way for it, but you do
bring into focus the fact that several different kinds of processing
are going on during interpretations -- not just EVAL alone, but there
is FUNVAL (if you will) to fetch the function part, there is DODECLS
to add to a declarations database [Maclisp had a functional counterpart
to DECLARE, which is why macroexpansion seemed like such a natural idea
there], and there is lambda-list parsing. I'd prefer to see a uniform
meta-expansion syntax -- such as defmacro -- but we may have to consider
context as per your suggestion.
You got it. That is exactly what I just said to Scott. Each of these
contexts should be identified separately, via a uniform mechanism.
That would fix ((mumble z) (mumble z)), i.e., make it -not- work.
∂13-May-85 1144 DCP%TENEX.SCRC@MIT-XX.ARPA hash table types
Received: from MIT-XX.ARPA by SU-AI.ARPA with TCP; 13 May 85 11:44:01 PDT
Received: by MIT-XX via Chaosnet; 13 May 85 14:38-EDT
Date: Sunday, 12 May 1985 10:56-EDT
From: David C. Plummer <DCP at SCRC-TENEX>
To: George J. Carrette <GJC at MIT-MC>
Subject: hash table types
cc: DCP at SCRC-QUABBIN, TIM at MIT-MC, COMMON-LISP at SU-AI
In-rely-to: <[MIT-MC].499100.850512.GJC>
Date: Sun, 12 May 85 08:51:09 EST
From: George J. Carrette <GJC@MIT-MC>
We figured that fixing the root of the problem, the lack of
canonicalization in the hardware database would possibly cost
enough time to break a production development window and put
off the introduction of a new hardware item for a few months,
with possible losses in sales of a million dollars or more
for the year. Given this sort of lossage mode one cant stress
enough the importance of having *some* way of getting
compatibility between RELEASE N and RELEASE N+1. Remember
that at some time in "zetalisp" EQUAL on type STRING meant
STRING-EQUAL, which was for better or worse case insensitive.
LMI release 2 and presumably also Symbolics release 6 does
away with this. If there is nothing available which behaves
in exactly the same way as the *old* EQUAL-HASH-TABLE then
people can be screwed badly. Remember also that many ugly
things that were left in Common-Lisp from maclisp days (such
as the empty list being a SYMBOL, making the set of all lists
and all symbols have a non-null intersection) were justified
soley on the basis that there was no *automatic* way for
people to detect if they were depending on such lossage and
convert their programs. To quote Dave Moon: "Our customers
just wont stand for it."
For that exact reason, "Our customers just won't stand for it",
Release 6 is compatible with Release 5 w.r.t. EQUAL-HASH-TABLEs,
i.e., case is ignoreed. Release 6 provides hints on how to write
code that will work in both Release 6 and Release 7, requiring
recompilation and possibly minimal, if any conversion. In
Release 7 there will most likely be a CASE-INSENSITIVE-HASH-TABLE
that uses CASE-INSENSITIVE-EQUAL as the predicate and
CASE-INSENSITIVE-EQUAL-HASH (unless EQUAL-HASH will continue to
ignore case).
More generally, and on the generic issue: Symbolics has had
generic hash tables for quite a while. I don't know if Lisp
Machine Lisp is general has. The definer of the hash table is
required to write two methods, the equality predicate and the
hash function. They are quite useful. All implementations must
do a dispatch, since the entrypoints are the same for all types
of hash tables. In a flavor-based implementation, the dispatch
happens at the message send level. In other implementations, my
guess is that FUNCALL is used where the function comes from some
defstruct slot. In any case, generalizing does not appear to be
a hard thing to implement.
The external things I see needing changing are
* An additional argument to make-hash-table. My vote for a name
is :hash-function.
* If the hash function is not provided, it defaults from the
predicate.
* It is an error not to supply a hash function if the predicate
is not one of those builtin (currently, EQ, EQL and EQUAL).
[Implementatyions may supply more builtins and opt not to
signal the error.]
* Requirements of the hash function: It must return an integer,
possibly restricted to fixnum, possibly required to be
positive. [The LispM builtin hash functions attempt to return
positive fixnums that use as many bits as possible. This is
so that there is more uniform distribution after it is MODed
with the hash table modulus.]
* Hints on how to write implementation independent, efficient
hash functions. This is the hardest part. Maybe there are
enough constants defined in the language to make this possible
(e.g., bits-per-fixnum, etc). Hmmm... Many LispM hash
functions use the functions ROT (better called ROTATE-FIXNUM)
and LSH (better called LOGICAL-SHIFT-FIXNUM). They often use
LOGXOR, but this is part of CLtL. I have a memory of being
told that ROT and LSH were consciously not part of the CL
language because they weren't mathematical. With names like
ROTATE-FIXNUM and LOGICAL-SHIFT-FIXNUM maybe they should be
put back? [Also see Turing's biography about the hardware
designers diking out his boolean instructions for similar
reasons.]
* The use of MAKNUM, %POINTER or
∂13-May-85 1145 DCP%TENEX.SCRC@MIT-XX.ARPA hash table types
Received: from MIT-XX.ARPA by SU-AI.ARPA with TCP; 13 May 85 11:44:50 PDT
Received: by MIT-XX via Chaosnet; 13 May 85 14:41-EDT
Date: Sunday, 12 May 1985 10:56-EDT
From: David C. Plummer <DCP at SCRC-TENEX>
To: George J. Carrette <GJC at MIT-MC>
Subject: hash table types
cc: DCP at SCRC-QUABBIN, TIM at MIT-MC, COMMON-LISP at SU-AI
In-rely-to: <[MIT-MC].499100.850512.GJC>
Date: Sun, 12 May 85 08:51:09 EST
From: George J. Carrette <GJC@MIT-MC>
We figured that fixing the root of the problem, the lack of
canonicalization in the hardware database would possibly cost
enough time to break a production development window and put
off the introduction of a new hardware item for a few months,
with possible losses in sales of a million dollars or more
for the year. Given this sort of lossage mode one cant stress
enough the importance of having *some* way of getting
compatibility between RELEASE N and RELEASE N+1. Remember
that at some time in "zetalisp" EQUAL on type STRING meant
STRING-EQUAL, which was for better or worse case insensitive.
LMI release 2 and presumably also Symbolics release 6 does
away with this. If there is nothing available which behaves
in exactly the same way as the *old* EQUAL-HASH-TABLE then
people can be screwed badly. Remember also that many ugly
things that were left in Common-Lisp from maclisp days (such
as the empty list being a SYMBOL, making the set of all lists
and all symbols have a non-null intersection) were justified
soley on the basis that there was no *automatic* way for
people to detect if they were depending on such lossage and
convert their programs. To quote Dave Moon: "Our customers
just wont stand for it."
For that exact reason, "Our customers just won't stand for it",
Release 6 is compatible with Release 5 w.r.t. EQUAL-HASH-TABLEs,
i.e., case is ignoreed. Release 6 provides hints on how to write
code that will work in both Release 6 and Release 7, requiring
recompilation and possibly minimal, if any conversion. In
Release 7 there will most likely be a CASE-INSENSITIVE-HASH-TABLE
that uses CASE-INSENSITIVE-EQUAL as the predicate and
CASE-INSENSITIVE-EQUAL-HASH (unless EQUAL-HASH will continue to
ignore case).
More generally, and on the generic issue: Symbolics has had
generic hash tables for quite a while. I don't know if Lisp
Machine Lisp is general has. The definer of the hash table is
required to write two methods, the equality predicate and the
hash function. They are quite useful. All implementations must
do a dispatch, since the entrypoints are the same for all types
of hash tables. In a flavor-based implementation, the dispatch
happens at the message send level. In other implementations, my
guess is that FUNCALL is used where the function comes from some
defstruct slot. In any case, generalizing does not appear to be
a hard thing to implement.
The external things I see needing changing are
* An additional argument to make-hash-table. My vote for a name
is :hash-function.
* If the hash function is not provided, it defaults from the
predicate.
* It is an error not to supply a hash function if the predicate
is not one of those builtin (currently, EQ, EQL and EQUAL).
[Implementatyions may supply more builtins and opt not to
signal the error.]
* Requirements of the hash function: It must return an integer,
possibly restricted to fixnum, possibly required to be
positive. [The LispM builtin hash functions attempt to return
positive fixnums that use as many bits as possible. This is
so that there is more uniform distribution after it is MODed
with the hash table modulus.]
* Hints on how to write implementation independent, efficient
hash functions. This is the hardest part. Maybe there are
enough constants defined in the language to make this possible
(e.g., bits-per-fixnum, etc). Hmmm... Many LispM hash
functions use the functions ROT (better called ROTATE-FIXNUM)
and LSH (better called LOGICAL-SHIFT-FIXNUM). They often use
LOGXOR, but this is part of CLtL. I have a memory of being
told that ROT and LSH were consciously not part of the CL
language because they weren't mathematical. With names like
ROTATE-FIXNUM and LOGICAL-SHIFT-FIXNUM maybe they should be
put back? [Also see Turing's biography about the hardware
designers diking out his boolean instructions for similar
reasons.]
* The use of MAKNUM, %POINTER or whatever it is for a particular
implementation is to be forbidden for user suplied hash
functions. This is because the GC can move objects and change
their addresses, and there is no way in CL to communicate this
between the hash table and the GC. Individual implementations
may wish to implement such a communication and allow %POINTER
and use it for builtin hash tables to improve efficiency.
Conclusion: generic hash tables are useful and probably simple to
implement. User supplied hash functions are required but
difficult.
Additionaly, I think there should be a CASE-INSENSITIVE-EQUAL
function and a corresponding (builtin) hash table type. I have
an uneasy feeling about EQUALP hash tables. I think the
uneasiness comes in the traversing of arbitrary array structure
that EQUALP implies and the possible inefficiency. The example
needs I have so far seen for EQUALP are dealt with by
CASE-INSENSITIVE-EQUAL.
∂14-May-85 0905 KESSLER@UTAH-20.ARPA &optional with &key
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 14 May 85 09:05:42 PDT
Date: Tue 14 May 85 10:05:01-MDT
From: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
Subject: &optional with &key
To: common-lisp@SU-AI.ARPA
If you provide an &optional followed by &key's, does that mean that
the &optional becomes required? The examples don't seem to address the
case:
((lambda (a &optional (b 3) &key c (d a))
(list a b c d x))
1 :c 7)
Is this an error (i.e. a is bound to 1, b is bound to :c and 7 causes
the error), or is a bound to 1, b bound to 3, c to 7 and d to 1.
Bob.
-------
∂14-May-85 0933 gls@AQUINAS.ARPA &optional with &key
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 14 May 85 09:33:08 PDT
Received: by THINK.ARPA with CHAOS id AA23862; Tue, 14 May 85 12:24:51 edt
Date: Tue, 14 May 85 12:25 EDT
From: Guy Steele <gls@AQUINAS.ARPA>
Subject: &optional with &key
To: kessler%utah-20@GODOT.ARPA
Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.ARPA
In-Reply-To: Your message of 14 May 85 12:05-EDT
Message-Id: <850514122500.1.GLS@DESIDERIUS.ARPA>
It isn't quite accurate to say that the presence of &key makes an
&optional parameter be required. It is true, however, that, if a
function has both &optional and &key parameters, it is impossible to
specify explicit arguments for any keyword parameters unless arguments
are first explicitly given for all optional parameters. The book
doesn't say so in one sentence, but you can deduce this from careful
reading of page 61. I agree that an explicit statement of this fact
would be worthwhile, and that an example would be useful.
--Guy
∂14-May-85 1002 RWK@SCRC-STONY-BROOK.ARPA &optional with &key
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 May 85 10:02:23 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 236361; Tue 14-May-85 12:57:41-EDT
Date: Tue, 14 May 85 13:02 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: &optional with &key
To: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 14 May 85 12:05-EDT from Robert R. Kessler <KESSLER@UTAH-20.ARPA>
Message-ID: <850514130227.0.RWK@CROW.SCRC.Symbolics.COM>
Date: Tue 14 May 85 10:05:01-MDT
From: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
If you provide an &optional followed by &key's, does that mean that
the &optional becomes required? The examples don't seem to address the
case:
((lambda (a &optional (b 3) &key c (d a))
(list a b c d x))
1 :c 7)
Is this an error (i.e. a is bound to 1, b is bound to :c and 7 causes
the error), or is a bound to 1, b bound to 3, c to 7 and d to 1.
-------
It is an error (i.e. A is bound to 1, B is bound to :C and 7 causes
the error). However, that is not the same as B being required!
All it means is that the keyword arguments start AFTER B. This
implies that you have to supply B in order to supply C or D, but
that's true in (a &optional (b 3) c (d a)), too.
∂14-May-85 1655 REM@IMSSS Semantic question about closures
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-May-14 15:55:04 PST (=GMT-8hr)
Date: 1985 May 14 15:54:28 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132167250130.G0353
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To: Common-LISP@SU-AI
Subject: Semantic question about closures
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up)
I have a question about closures in CL. When a closure is made, with
some variable encapsulated in the closure, is that variable accessible
only with the exact function that was closed (thus somehow a copy of
the gut function must be made such that it internally references that
closure-cell directly rather than how the gut function in vacuuo would
reference that named variable), or is that variable accessible also
from any function called by the closure (thus we can implement a
closure by fluid-binding the closure-variable as we pass from the
closure into the gut function and copying the final value of the
fluid-binding back into the closure-cell when returning)? I.e. if
function A binds special X to some initial value, makes a closure of B
with free variable X referring to A's fluid-binding of X, then
lambda-binds X another level deep to a new value, then calls
B-closure, obviously references to X within B-closure will get the
first binding of X, but if B calls C which also refers to free
variable X does C get the closure-of-first-binding-of-X inherited from
closure-B or does C get the second-fluid-binding-of-X inherited
directly from A skipping over B?
∂14-May-85 1858 RAM@CMU-CS-C.ARPA Semantic question about closures
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 14 May 85 18:58:32 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Tue 14 May 85 21:58:40-EDT
Date: Tue, 14 May 1985 21:58 EDT
Message-ID: <RAM.12111074390.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: REM%IMSSS@λSU-SCORE.ARPA (temporary until nameservers up)λ
Cc: Common-LISP@SU-AI.ARPA
Subject: Semantic question about closures
In-reply-to: Msg of 1985 May 14 15:54:28 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>
Date: 1985 May 14 15:54:28 PST (=GMT-8hr)
From: Robert Elton Maas <REM at IMSSS.SU.EDU>
Re: Semantic question about closures
When a closure is made, with some variable encapsulated in the
closure, is that variable accessible only with the exact function
that was closed (...), or is that variable accessible also from any
function called by the closure...
The value is not visible. This is exactly what lexical scoping means.
A variable DOES NOT EXIST outside of code textually enclosed by the
binding form. You shouldn't worry about closures when trying to
understand lexical variables--- closures are just an implementation
detail.
I think that you are confusing yourself by talking about "free
variables"; this is not a very useful concept in Common Lisp. Instead
you should think in terms of special variables and lexical variables.
Special variables and lexical variables have very different semantics,
and the language has possibly done a disservice by making them appear
to be similar.
The operation of "binding" a lexical variable is quite unlike that of
binding a special. Binding a lexical variable actually creates a new
"variable" which is then associated with that name within the lexical
scope. By a "variable", I mean a nameless memory location which can be
used for storing a value. The fact that some variables can be stack
allocated is unimportant for understanding what a piece of code does.
The reason that the called function in your example cannot see the
original variable is that its variable is totally different from the
one in the calling function, although it does happen to have the same
name. The fact that it has the same name is totally irrelevant,
since the association of name with variable does not exist outside of
the lexical context in which the variable was created.
It is important to draw the distinction between variables and names.
This may be difficult for people whose primary experience is with
old-fashioned shallow/special-binding lisps, since in these
implementations there is a one-to-one correspondence between variables
(value cells) and names (symbols).
(thus somehow a copy of the gut function must be
made such that it internally references that closure-cell directly
rather than how the gut function in vacuuo would reference that
named variable)
Your parenthetical inference is incorrect, however. There is no "gut
function" to copy. The compiler must determine at compile time
whether it is going to close over a variable. If it decides to close
over variables, it compiles code to access closure variables. Lexical
variable references do not exist "in vacuo". A lexical variable is
created when it is bound.
I.e. if function A binds special X to some initial value, makes a
closure of B with free variable X referring to A's fluid-binding
of X, ...
Special variables are not closed over. The meaning of a special
variable reference is "give me the most recent binding in my current
dynamic context." This is incompatible with the notion of closing
over variables.
Rob
∂14-May-85 2103 WHOLEY@CMU-CS-C.ARPA Apply-But-Last
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 14 May 85 21:02:53 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Wed 15 May 85 00:03:04-EDT
Date: Wed, 15 May 1985 00:02 EDT
Message-ID: <WHOLEY.12111097035.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Common-Lisp@SU-AI.ARPA
Subject: Apply-But-Last
From: vanroggen@DEC-HUDSON
Subject: SETF APPLY ...
It seems to me that we could have both the newvalue passed as the
last arg of the setting function and the ability to do SETF of
APPLY if we would admit to a function, that I'll call APPLY-BUT-LAST,
that's just like APPLY, except that it's the next-to-last argument
that must be a list, and the last argument is just passed as the
last argument to the applied function.
That name is misleading (too much in common with some list manipluation
functions), and the effect can be obtained portably (and reasonably efficiently
(even with dumb compilers)) with Multiple-Value-Call:
(multiple-value-call #'function arg1 arg2 ...
(values-list rest-arg)
last-arg)
--Skef
∂15-May-85 1221 REM@IMSSS Another question about lexical closures
Received: from IMSSS by SU-AI with PUP; 15-May-85 12:20 PDT
Date: 15 May 1985 0213-PDT
From: Rem@IMSSS
Subject: Another question about lexical closures
To: COMMON-LISP@SU-AI
There's a little ambiguity about when two bindings are "the same" and when
they are "different" bindings. If you bind exactly the same lexical variable
(in the same function or other executable form) to exactly the same value
(the values are EQ), at two different times, are the two bindings you get
considered to be the same or different? I.e. if you make a lexical closure
in function FOO with X bound to NIL and then make another lexical closure
in function FOO with X bound to NIL, will the X-variables in those two
closures be the same variable (sharing side-effects) or not? My guess
is they will be different, that is each time you go into a lambda-binding
you get a "different" binding even if the lexical variable and its value
are the same both times. Am I correct? (Note the example at the bottom of
page 87 doesn't answer this question since TWO-FUNS is called only once.
If it got called a second time, with exactly the same args, and the result
SETQ'd to global FUNS2, would (CAR FUNS) and (CAR FUNS2) share their
lexical-closure-variable, i.e. "the binding of the variable X created
on entry to the function TWO-FUNS when it was called with argument 6"
as described at the bottom of the page? That phrasing indicates there
WOULD be sharing, but due to what it says on page 37 top "it depends
on the invocaton during which the reference is made" I think it WOULD NOT
be sharing, i.e. wording on page 87 should really say "... on that particular
entry to the function TWO-FUNS ..." even though in that example it is moot
since TWO-FUNS was called only once in the example.)
-------
∂15-May-85 1233 MOON%TENEX.SCRC@MIT-XX.ARPA Validation
Received: from MIT-XX.ARPA by SU-AI.ARPA with TCP; 15 May 85 12:18:26 PDT
Received: by MIT-XX via Chaosnet; 15 May 85 02:40-EDT
Date: Tuesday, 14 May 1985 21:38-EDT
From: MOON at SCRC-TENEX
To: Dick Gabriel <RPG at SU-AI.ARPA>
Cc: ohlander at USC-ISI.ARPA, quinquevirate at SU-AI.ARPA,
squires at USC-ISI.ARPA
Subject: Validation
In-reply-to: The message of 08 May 85 2246 PDT from Dick Gabriel <RPG@SU-AI.ARPA>
Date: 08 May 85 2246 PDT
From: Dick Gabriel <RPG@SU-AI.ARPA>
The point of keeping (some) of the validation code `secret' is to
make sure that people don't cheat and get exactly the validation
code to work. I believe that is approximtely owow ADA is done.
I would also be in favor of doing it exactly the way ADA is done:
have a public validation suite along with a `secret' one. When the
public one has passed, the public and the private ones are applied
by the testors.
I think this idea is totally preposterous!
Until Common Lisp is used as widely as Ada, until Common Lisp is used in
systems on which human life depends, and until as much money is thrown into
Common Lisp as is thrown into Ada, let's not worry so much about setting up
elaborate bureaucracies and complex mechanisms to deal with the possibility
of cheating. Until Common Lisp is as rigorously defined as Ada, how are
you going to respond to an implementor of a Common Lisp that fails the
secret validation suite who says "My implementation is correct, your
validation suite must be broken. Show me what it does."?
I believe that it is neither feasible nor desirable to validate Common Lisp
as rigorously as Ada is validated (at present). We're going to have a hard
enough time doing any validation at all, so let's not burden ourselves with
creating two validation suites and trying to keep one of them secret.
Question of fact: what is the ratio between the calendar 1986 budget for
Ada validation and the calendar 1986 budget for Common Lisp validation? To
stimulate discussion, I will make an uninformed guess: I believe that the
ratio is between 1,000 and 5,000. I wouldn't be surprised to learn that my
guess is much too low. Think about it.
I have no objection to the rest of your proposal.
∂15-May-85 1331 RWK@SCRC-STONY-BROOK.ARPA Another question about lexical closures
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 May 85 13:31:39 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 237413; Wed 15-May-85 16:26:05-EDT
Date: Wed, 15 May 85 16:30 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Another question about lexical closures
To: Rem@IMSSS
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 15 May 85 05:13-EDT from Rem@IMSSS
Message-ID: <850515163014.9.RWK@CROW.SCRC.Symbolics.COM>
Date: 15 May 1985 0213-PDT
From: Rem@IMSSS
There's a little ambiguity about when two bindings are "the same" and when
they are "different" bindings. If you bind exactly the same lexical variable
(in the same function or other executable form) to exactly the same value
(the values are EQ), at two different times, are the two bindings you get
considered to be the same or different?
The way I think of this is "Two calls to LET produce two different
bindings". So if I read your question right, the answer is "different".
I.e. if you make a lexical closure
in function FOO with X bound to NIL and then make another lexical closure
in function FOO with X bound to NIL, will the X-variables in those two
closures be the same variable (sharing side-effects) or not?
I assume here you mean two calls to FOO, not something like
(LET ((X 5))
(VALUES #'(LAMBDA () X) #'(LAMBDA (Y) (SETQ X Y))))
where the answer is "save variable (sharing side effects)"
My guess
is they will be different, that is each time you go into a lambda-binding
you get a "different" binding even if the lexical variable and its value
are the same both times. Am I correct?
Yes.
(Note the example at the bottom of
page 87 doesn't answer this question since TWO-FUNS is called only once.
Indeed, I think this section could use a bit more exposition and further
examples. I think the manual can't help being a bit of a language
tutorial here, and should abandon the tersness of a reference manual,
even if it ends up repeating the same concept in different ways.
If it got called a second time, with exactly the same args, and the result
SETQ'd to global FUNS2, would (CAR FUNS) and (CAR FUNS2) share their
lexical-closure-variable, i.e. "the binding of the variable X created
on entry to the function TWO-FUNS when it was called with argument 6"
as described at the bottom of the page? That phrasing indicates there
WOULD be sharing, but due to what it says on page 37 top "it depends
on the invocaton during which the reference is made" I think it WOULD NOT
be sharing, i.e. wording on page 87 should really say "... on that particular
entry to the function TWO-FUNS ..." even though in that example it is moot
since TWO-FUNS was called only once in the example.)
-------
That's right. There would be sharing between (CAR FUNS) and (CADR FUNS), and
between (CAR FUNS2) and (CADR FUNS2), but not between the elements of FUNS
and FUNS2.
∂15-May-85 1332 RWK@SCRC-STONY-BROOK.ARPA Another question about lexical closures
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 May 85 13:32:17 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 237418; Wed 15-May-85 16:26:43-EDT
Date: Wed, 15 May 85 16:30 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Another question about lexical closures
To: Rem%IMSSS@SU-SCORE.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 15 May 85 05:13-EDT from Rem@IMSSS
Supersedes: <850515163014.9.RWK@CROW.SCRC.Symbolics.COM>,
<850515163043.0.RWK@CROW.SCRC.Symbolics.COM>
Message-ID: <850515163051.1.RWK@CROW.SCRC.Symbolics.COM>
Date: 15 May 1985 0213-PDT
From: Rem@IMSSS
There's a little ambiguity about when two bindings are "the same" and when
they are "different" bindings. If you bind exactly the same lexical variable
(in the same function or other executable form) to exactly the same value
(the values are EQ), at two different times, are the two bindings you get
considered to be the same or different?
The way I think of this is "Two calls to LET produce two different
bindings". So if I read your question right, the answer is "different".
I.e. if you make a lexical closure
in function FOO with X bound to NIL and then make another lexical closure
in function FOO with X bound to NIL, will the X-variables in those two
closures be the same variable (sharing side-effects) or not?
I assume here you mean two calls to FOO, not something like
(LET ((X 5))
(VALUES #'(LAMBDA () X) #'(LAMBDA (Y) (SETQ X Y))))
where the answer is "save variable (sharing side effects)"
My guess
is they will be different, that is each time you go into a lambda-binding
you get a "different" binding even if the lexical variable and its value
are the same both times. Am I correct?
Yes.
(Note the example at the bottom of
page 87 doesn't answer this question since TWO-FUNS is called only once.
Indeed, I think this section could use a bit more exposition and further
examples. I think the manual can't help being a bit of a language
tutorial here, and should abandon the tersness of a reference manual,
even if it ends up repeating the same concept in different ways.
If it got called a second time, with exactly the same args, and the result
SETQ'd to global FUNS2, would (CAR FUNS) and (CAR FUNS2) share their
lexical-closure-variable, i.e. "the binding of the variable X created
on entry to the function TWO-FUNS when it was called with argument 6"
as described at the bottom of the page? That phrasing indicates there
WOULD be sharing, but due to what it says on page 37 top "it depends
on the invocaton during which the reference is made" I think it WOULD NOT
be sharing, i.e. wording on page 87 should really say "... on that particular
entry to the function TWO-FUNS ..." even though in that example it is moot
since TWO-FUNS was called only once in the example.)
-------
That's right. There would be sharing between (CAR FUNS) and (CADR FUNS), and
between (CAR FUNS2) and (CADR FUNS2), but not between the elements of FUNS
and FUNS2.
∂15-May-85 1354 STENGER%ti-csl.csnet@csnet-relay.arpa adding PARSE-BODY primitive
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 15 May 85 13:53:56 PDT
Received: from ti-csl by csnet-relay.csnet id am03561; 15 May 85 2:01 EDT
Date: 14 May 1985 1011-CDT
From: Dan Stenger <STENGER%ti-csl.csnet@csnet-relay.arpa>
Subject: adding PARSE-BODY primitive
To: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 6-May-85 1043-CDT
Received: from csl60 by ti-csl; Tue, 14 May 85 10:09 CST
I am all for adding the PARSE-BODY function. Every implementation has to
have this code in it anyway and since it is generally useful why not
standardize it.
Dan Stenger
-------
∂15-May-85 1643 J.Dalton%edxa@Ucl-Cs.ARPA lexical closures
Received: from UCL-CS.ARPA by SU-AI.ARPA with TCP; 15 May 85 16:42:36 PDT
Received: from edxa.ac.uk by 44d.Ucl-Cs.AC.UK via Janet with NIFTP id a011256;
16 May 85 0:39 BST
From: DALTON FHL (on ERCC DEC-10) <J.Dalton%edxa@ucl-cs.arpa>
Date: Wednesday, 15-May-85 23:06:16-GMT
Message-ID: <132170-754-714@EDXA>
To: Common-Lisp <Common-Lisp%su-ai.arpa@ucl-cs.arpa>,
J.Dalton%edxa@ucl-cs.arpa
Subject: lexical closures
--------
Closures ...
Date: 1985 May 14 15:54:28 PST (=GMT-8hr)
From: Robert Elton Maas <REM@imsss.su.edu>
I.e. if function A binds special X to some initial value, makes a
closure of B with free variable X referring to A's fluid-binding of X,
then lambda-binds X another level deep to a new value, then calls
B-closure, obviously references to X within B-closure will get the
first binding of X,
It turns out that the B-closure will refer to the second (deeper) value of
X, but not because of anything involving closures. Lexical closures in
Common Lisp do not include special variables [see pp 39-40]. If X is
a special variable, the free X in B will always refer to the most recent
binding of X; lexical closures don't change this.
One reason for the confusion may be that other dialects of Lisp, such as
ZetaLisp and Franz, do provide closures over special variables that work
more or less in the way you describe.
Date: 15 May 1985 0213-PDT
From: Rem@imsss
Subject: Another question about lexical closures
There's a little ambiguity about when two bindings are "the same" and when
they are "different" bindings. If you bind exactly the same lexical variable
(in the same function or other executable form) to exactly the same value
(the values are EQ), at two different times, are the two bindings you get
considered to be the same or different?
If you call the same function twice, you get two different bindings (p 36:
"a new binding is established on every invocation"). The text on pages
87-89 seems clear on what this means for closures, particularly the example
in the middle of page 88 (think of each LET as a function call). Now if
TWO-FUNS were called twice, there would be two different bindings of X, and
closures involving different bindings must be different if the bound values
could be changed by SETQ. Since the second of them includes a SETQ, the
closures returned in the list must be different each time. Now if it weren't
for the SETQ, each call to TWO-FUNS would still normally return different
closures because X might have a different value each time. If two calls
happened to use the same EQ value twice, I don't see anything to guarantee
that the closures would be different (after all, they would be
"behaviorially identical with respect to invocation"), but would any
implementation notice that they could be the same?
So I think the book is fairly clear, although you might have to reread it
a few times if you aren't already familiar with the stuff involved.
--------
∂01-Jun-85 0859 RPG Preposterousness
To: quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA,
squies@USC-ISI.ARPA
What happens when an implementor says, ``your test case is wrong,
show me what it does'' is this: we show him (or her) what it does.
There is nothing magic about a `secret' test suite except that
it encourages people to implement all of the nooks and crannies
rather than exactly the ones in the test suite. To develop a
second test suite, you simply remove a fraction of the original
single one. I presume the point of the public suite is to inform
the implementors of the coverage of the tests. At the moment,
I could put together these 2 suites in about 1 day from the
total suite I have now - so what's the big deal?
The facts regarding an implementation are simply part of the
validation process. The decision as to whether an implementation
as given satisifies the specification of CL is a matter I do
not address. Perhaps it will turn out that PSL as it is today
is a Common Lisp.
In terms of the need for validation: when I hear some of the schemes
for using AI by the DoD and NASA, I think more and more about
making these Lisp systems solid. I think that a small investment
in validation can make a significant difference, even if the difference
is the result of increased diligence generated by concern about the
`secret' suite.
-rpg-
∂16-May-85 1845 Masinter.pa@Xerox.ARPA Re: Macros -> declarations
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 16 May 85 18:43:29 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 16 MAY 85 14:59:19 PDT
Date: 16 May 85 14:53 PDT
From: Masinter.pa@Xerox.ARPA
Subject: Re: Macros -> declarations
In-reply-to: various
To: common-lisp@SU-AI.ARPA
The only reason for this issue is because the interpreter has to look
ahead for SPECIAL declarations. SPECIAL declarations are the only ones
that have any semantic import. Furthermore, SPECIAL declarations are the
only ones that are textually retroactive, in that they apply to things
that appeared BEFORE the declaration rather than after.
Rather than hacking around the deficiencies of DECLARE, why not change
it? Put SPECIAL declarations where they belong, next to the variable.
Leave all the other declarations where they are. Most of these issues
then become moot, and we can even consider freeing up some of the
restrictions on declarations; it would seem reasonable to allow
declarations anywhere in an implicit PROGN to refer to the stuff that
follows.
∂16-May-85 1847 FAHLMAN@CMU-CS-C.ARPA Preposterousness
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 16 May 85 18:47:36 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 16 May 85 21:16:45-EDT
Date: Thu, 16 May 1985 14:46 EDT
Message-ID: <FAHLMAN.12111519930.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA, squires@USC-ISI.ARPA
Subject: Preposterousness
In-reply-to: Msg of 1 Jun 1985 11:59-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
I guess I side with RPG on this one. It's important that the public
validation suite test all those things that are going to be tested, so
that if your program runs the public code and you're not deliberately
trying to out-trick the test, you are nearly certain to pass the secret
test as well. But I see no problem, and some advantage, to having a
bunch of additional tests that are kept private, just to keep people
from cutting corners by "tuning" against the actual cases that appear in
the test.
On the assumption that nobody else was going to provide any validation
code, I hired a couple of high-school kids (good ones) and have been
training them up to the point where they could write the relatively
simple parts of a validation suite, starting in a couple of weeks.
Since RPG is so close to having a complete test suite, I'll put these
people to work on other things unless I hear of validation code that
needs to be written. (They are not ready to write the test code for
hairy arglist parsing or anything like that.)
Since I'm writing to this group anyway, let me toss out an idea I've
already mentioned to Gabriel: now that the interesting question is whose
Common Lisp is fastest on various things, and not whether Common Lisp
beats Interlisp or Maclisp or PSL, the business of benchmarking programs
becomes easier. It would be a relatively simple matter for someone to
collect a bunch of fairly large, realistic programs written in portable
Common Lisp, and to use these for testing one Common Lisp against
another. Examples might be a smallish system written in portable OPS5,
the Spice Lisp compiler, somebody's natural language system, etc. No
longer do we have to use tiny benchmarks because they are the only ones
people are willing to translate. No longer do we have to avoid timing
string code because not all Lisps have strings.
This sort of thing might make a good follow-up to RPG's study, if
someone can be found to coordinate it. After listening to RPG's war
stories, however, I doubt that any of us would be interested in
coordinating this -- we need some poor soul who either doesn't know what
he's getting into or who actually likes taking public abuse.
-- Scott
∂16-May-85 1946 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 16 May 85 19:45:56 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 16 May 85 22:45:05-EDT
Date: Thu, 16 May 1985 22:45 EDT
Message-ID: <FAHLMAN.12111607133.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Masinter.pa@XEROX.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 16 May 1985 17:53-EDT from Masinter.pa at Xerox.ARPA
We've kicked this idea around before in various forms, including the use
of some sort of syntactic marker on special bindings -- something like
turning FOO into $FOO if the variable is special, or treating the *FOO*
convention as being a declaration of specialness. Other lexical Lisps
have done this sort of thing with no obvious ill effects (and arguably
some good effects), but it seems to have been too radical a change to
have been seriously considered by most of the Common Lisp people when
the language was being designed. It would be even tougher now that the
langauge is starting to be used and assorted companies are rushing to
get implementations out.
Personally, I like the idea. I've felt for some time that we ought to
separate SPECIAL declarations from all the others, even if that means
that Common Lisp ends up looking a little different from Maclisp. But
we should only make this move so late in the game if just about everyone
else feels likewise.
-- Scott
∂16-May-85 2007 GRISS%hp-hulk.csnet@csnet-relay.arpa Collections of CL tests and validations
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 16 May 85 20:07:23 PDT
Received: from hplabs by csnet-relay.csnet id ae15232; 16 May 85 18:38 EDT
Received: by HP-VENUS id AA13027; Thu, 16 May 85 05:31:14 pdt
Message-Id: <8505161231.AA13027@HP-VENUS>
Date: Thu 16 May 85 05:31:09-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Collections of CL tests and validations
To: common-lisp@su-ai.ARPA
Cc: GRISS@hplabs.CSNET
Source-Info: From (or Sender) name not authenticated.
Has anyone started to collect or distribute a CL validation suite or
even scattered tests of CL. Are any of these publically available?
Thanks
Martin Griss
-------
∂16-May-85 2346 RPG Benchmarking
To: quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA,
squires@USC-ISI.ARPA
The original intent of the benchmark study was to use large, real
programs as benchmarks. We were unable to do that because not all
Lisps supportted all things - this is as Scott suggested. To benchmark
Common Lisps, though, we can use such large programs. Because I'm
used to the abuse now, I'd be happy to continue with it.
-rpg-
∂17-May-85 0129 REM@IMSSS Property lists
Received: from IMSSS by SU-AI with PUP; 17-May-85 01:29 PDT
Date: 17 May 1985 0128-PDT
From: Rem@IMSSS
Subject: Property lists
To: COMMON-LISP@SU-AI
It seems to me that the choice of whether property lists should be kept
as ASSOC lists or as alternating lists should be an implementation issue.
Functions for adding, deleting, finding, modifying them should exist
so that the user hardly ever needs to actually see the structure except
when debugging. Yet the CL manual insists that in CL they must be implemented
as alternating lists, not as ASSOC lists. Why was this decision made??
Should it be rescinded?
-------
∂17-May-85 0544 KMP@SCRC-QUABBIN.ARPA Property lists
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 May 85 05:44:03 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 164444; Fri 17-May-85 08:38:41-EDT
Date: Fri, 17 May 85 08:43 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Property lists
To: Rem@IMSSS, COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 17 May 85 04:28-EDT from Rem@IMSSS
Message-ID: <850517084324.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 17 May 1985 0128-PDT
From: Rem@IMSSS
It seems to me that the choice of whether property lists should be kept
as ASSOC lists or as alternating lists should be an implementation issue.
Functions for adding, deleting, finding, modifying them should exist
so that the user hardly ever needs to actually see the structure except
when debugging. Yet the CL manual insists that in CL they must be implemented
as alternating lists, not as ASSOC lists. Why was this decision made??
Should it be rescinded?
No.
For one thing, the term "property list format" provides useful terminology
for contrasting "association list format".
For another thing, GETF has a variety of uses in situations where lists were
not actually created by (SETF (GETF ...)), etc. eg, keyword argument lists can
be easily manipulated using GETF. You couldn't do that if the format wasn't
defined. Instead, you'd write code identical to what's there just so that you
could use it "safely". Since there are advantages to saying what the format is
and no particular disadvantages (data abstractions notwithstanding; you could
always write a TABLE abstraction), it has been the concensus that the format
might as well be documented.
-kmp
∂17-May-85 0621 KMP@SCRC-QUABBIN.ARPA Macros -> declarations
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 May 85 06:21:04 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 164450; Fri 17-May-85 09:15:42-EDT
Date: Fri, 17 May 85 09:20 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Macros -> declarations
To: Fahlman@CMU-CS-C.ARPA, Masinter.pa@XEROX.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12111607133.BABYL@CMU-CS-C.ARPA>
Message-ID: <850517092025.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Thu, 16 May 1985 22:45 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
We've kicked this idea around before in various forms, including the use
of some sort of syntactic marker on special bindings -- something like
turning FOO into $FOO if the variable is special, or treating the *FOO*
convention as being a declaration of specialness. Other lexical Lisps
have done this sort of thing with no obvious ill effects (and arguably
some good effects), but it seems to have been too radical a change to
have been seriously considered by most of the Common Lisp people when
the language was being designed. It would be even tougher now that the
langauge is starting to be used and assorted companies are rushing to
get implementations out.
Personally, I like the idea. I've felt for some time that we ought to
separate SPECIAL declarations from all the others, even if that means
that Common Lisp ends up looking a little different from Maclisp.
Referring specifically to your comments about a standard (enforced) naming
convention for specials...
* For the record, some programs like Macsyma use the printname of symbols to
record other kinds of information and would have to be radically restructured
to adapt to such a scheme. eg, in Macsyma any symbol with $ is accessable to
the Macsyma user; ie, the macsyma expression FOO+BAR parses to something involving
the Lisp symbols $FOO and $BAR. Since there need to be some special variables
accessible to users and others which are not, this kind of change would cause
all kinds of hassle.
Admittedly, such a convention is just poor excuses for a package system,
but its semantics is much different than the CL package system and it's not a
trivial syntactic change to convert things.
I suspect this isn't an isolated example. The Programmer's Apprentice has a
ton of code (by Dick Waters) which prefixes a digit to every symbol so you
can tell what module it belongs to. eg, its "database" code uses names like
8FOO and 8BAR while the display module uses 7FOO and 7BAR. I suppose a
-very- careful Query Replace of "DISPLAY:" for "7" would almost "fix" things,
but it'd be fairly tricky.
* In general, I would want to avoid attaching language semantics to the print
name of a symbol. It's bad enough that all symbols with & as their first
char or that are interned on the keyword package are reserved. For example,
if specials had different print names than other symbols, you'd need to
add a :SPECIAL-P keyword to GENTEMP which said whether to do hair to make
sure the symbol had a print name suitable to be a special variable. Various
other applications that concatentated symbols to make new symbols in macros
would have to use care not to produce symbols like OLD-*FOO* (preferring,
I suppose *OLD-*FOO*) or OLD-$FOO (preferring $OLD-$FOO). There used to be
something nice about the sanctity of a symbol ... I feel as if we're starting
to walk all over that. I hope we will move -away- from having reserved symbols.
eg, eventually (might take a while before we can swing it) flushing &keywords
in the bvl for :keywords, and making :keywords not be SYMBOLP.
... But we should only make this move so late in the game if just about
everyone else feels likewise.
Wouldn't want you to think they did.
∂17-May-85 0731 JLW ∂10-May-85 0146 hoey@nrl-aic Re: EQUALP hash tables (and more ...)
To: Hoey@NRL-AIC.ARPA
CC: common-lisp@SU-AI.ARPA
Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 10 May 85 01:46:39 PDT
Date: 10 May 1985 03:54:51 EDT (Fri)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: EQUALP hash tables (and more ...)
To: Jon White <JLW@SU-AI.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Message-Id: <484559691/hoey@nrl-aic>
Date: 09 May 85 2356 PDT
From: Jon White <JLW@SU-AI.ARPA>
... a more generalized form of hashing ... two more "properties" of
hashtables -- the "equivalenceing" function, and the "numericalizing"
function....
For "equivalence" function, the user may supply #'eq, #'string=, or
even something random like #'=-mod-5;
Bravo! If CL should have hash tables, it should have these. The
existing lack of functionality is embarrassing in an otherwise
orthogonal, extensible language.
... the "numericalizing" function is simply how to reduce a general
s-expression into a reasonable sized fixnum....
I would leave off ``reasonable sized''; certainly gethash is capable of
hashing a fixnum value to its favorite range.
I [believe] hashing on EQ means using the pointer address...
but nothing in the CLM would prevent an implementation from using sxhash
instead.
Two problems with this. First, as you note, the key could get
modified. I'm not sure you noticed, but this means that in order for
GETHASH to fail, it would have to examine the whole table for modified
structures. Second, I think SXHASH might not terminate on circular
structures, though this caveat is not in the manual (and it, or its
denial, should be).
Dan
SXHASH on circular structures?
In-reply-to: your message of 10-May-85 3:54:51 EDT
Yes, one might implement SXHASH in a manner that would loop on circular
structures, but there is no requirement to do so. In fact, the CLM is
so vague about sxhash that (defun sxhash (x) 1) is a perfectly legitimate
definition!
I think there has been a common misconception about sxhash that it must
descend into every node of a structure; indeed, the first implementation
in pdp10 MacLisp, over a decade ago, did just that (and I'm no doubt the
guilty party). But more recently, I (and others) have experimented with
definitions which are depth-limited. [Similarly, during the NIL development,
both NIL and pdp10 MacLisp got definitions for a number of functions which were depth-limited, solely as a (slow) way to stop
depth-limiting; this was done primarily as a low-overhead, fail-safe way to
detect circularities. However, a fairly large limit has to be allowed, and thus
this idea has a loop hole on "blam" lists given to EQUAL; but it effectively
and somewhat quickly stop circularites on LENGTH, NTH, and a few others.]
But the purpose of SXHASH is to provide a user interface to the "numericalizing"
function needed for hash arrays; there is no need to make it more discriminatory
that would be useful in providing a moderately random distribution of collision
chains in hash tables. SXHASH is a many-to-one mapping, and there is no reason
to assume that, statistically speaking, the depth cutoff is more damaging than
is the accidental coinciding of a particular dataset -- one might think of this
"accidental coinciding" as the inherent noise in the information of the problem.
Of course, too small a limit on the depth would certainly be noticeable in
terms of the *average* speed of hashing functions, but just exactly where
that boundary is may be difficult to determine. [I wouldn't seriously
suggest using a constant function, or even one that merely discriminated
on the data type -- but can anyone seriously suggest that depth 1000 will
be statistically different from depth 100? I would like to know.]
For some months now, Lucid Common Lisp has been running with variations on
the limited-depth sxhash, and not only does it meet the CLM requirements,
but it seems to meet our day-to-day needs.
-- JonL --
∂17-May-85 0735 JLW SXHASH on circular structures?
To: Hoey@NRL-AIC.ARPA
CC: common-lisp@SU-AI.ARPA
In-reply-to: your message of 10-May-85 3:54:51 EDT
Yes, one might implement SXHASH in a manner that would loop on circular
structures, but there is no requirement to do so. In fact, the CLM is
so vague about sxhash that (defun sxhash (x) 1) is a perfectly legitimate
definition!
I think there has been a common misconception about sxhash that it must
descend into every node of a structure; indeed, the first implementation
in pdp10 MacLisp, over a decade ago, did just that (and I'm no doubt the
guilty party). But more recently, I (and others) have experimented with
definitions which are depth-limited. [Similarly, during the NIL development,
both NIL and pdp10 MacLisp got definitions for a number of functions which were depth-limited, solely as a (slow) way to stop
depth-limiting; this was done primarily as a low-overhead, fail-safe way to
detect circularities. However, a fairly large limit has to be allowed, and thus
this idea has a loop hole on "blam" lists given to EQUAL; but it effectively
and somewhat quickly stop circularites on LENGTH, NTH, and a few others.]
But the purpose of SXHASH is to provide a user interface to the "numericalizing"
function needed for hash arrays; there is no need to make it more discriminatory
that would be useful in providing a moderately random distribution of collision
chains in hash tables. SXHASH is a many-to-one mapping, and there is no reason
to assume that, statistically speaking, the depth cutoff is more damaging than
is the accidental coinciding of a particular dataset -- one might think of this
"accidental coinciding" as the inherent noise in the information of the problem.
Of course, too small a limit on the depth would certainly be noticeable in
terms of the *average* speed of hashing functions, but just exactly where
that boundary is may be difficult to determine. [I wouldn't seriously
suggest using a constant function, or even one that merely discriminated
on the data type -- but can anyone seriously suggest that depth 1000 will
be statistically different from depth 100? I would like to know.]
For some months now, Lucid Common Lisp has been running with variations on
the limited-depth sxhash, and not only does it meet the CLM requirements,
but it seems to meet our day-to-day needs.
-- JonL --
∂17-May-85 0803 gls%AQUINAS@THINK.ARPA Poor excuse for packages
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85 07:38:10 PDT
Received: by THINK.ARPA with CHAOS id AA04932; Fri, 17 May 85 10:31:42 edt
Date: Friday, 17 May 1985, 10:32-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Poor excuse for packages
To: common-lisp%sail@THINK.ARPA
Cc: gls%AQUINAS@THINK.ARPA
Message-Id: <850517103227.1.GLS@DESIDERIUS.ARPA>
KMP hinted at a very interesting solution to the special-variables
problem: let symbols in the package SPECIAL name special variables,
and let all others name local variables. There doesn't seem to be
much wrong with
(LET ((SPECIAL:MY-GLOBAL-FLAG 43)
(SPECIAL:PRINT-PRETTY T))
...)
or
(DEFUN FOO (A B SPECIAL:C) ...)
It's cheap to detect, too, in interpreter or compiler: just check the
package cell. This I like. Too bad it's too late.
An ugly suggestion is to ADD this mechanism to the language without
removing the declaration syntax yet, and let people phase over during
the next year. Ugh, bletch.
∂17-May-85 0803 Masinter.pa@Xerox.ARPA Re: Macros -> declarations
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 17 May 85 07:44:25 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAY 85 07:42:47 PDT
Date: 17 May 85 07:42 PDT
From: Masinter.pa@Xerox.ARPA
Subject: Re: Macros -> declarations
In-reply-to: KMP, Fahlman
To: common-lisp@SU-AI.ARPA
There are two alternatives for dealing with specials, both of which
remove SPECIAL from DECLARE. One is lexographic, relying on the
characters of the symbol. (Examples include inferring specialness from
*var* or $var, or, the Fortan II approach: special variables all begin
with the letters P, Q or S :-).
Another is syntactic; still allow arbitrary variables to be special, but
denote them in a way that removes the declaration from the (optional)
DECLARE syntax. For example, one might allow, at the "top level", a
special form
(SPECIAL var1 var2 .... varn)
and also, in any place where a variable is bound (LET, DO, lambda lists,
etc.), allow (SPECIAL var) wherever var is allowed.
(This leads to a bit of a burden if you want a
special-optional-variable, because you have to say something like
(lambda (a b &optional ((special c))) --)
- - - - - - - - - - - - - -
I will attempt to step gently around the sticky issue of how "Common
Lisp" should balance implementation inertia against technical advances,
and restrict myself to comments about the form of inertia.
There are two kinds of inertia: implementations of "Common Lisp" and
programs implemented in it. It would seem that there is some confusion
among the implementations on whether macros are or are not allowed to
expand into declarations. I would claim that, at least the syntactic
example above represents no more turmoil to the typical compiler and
interpreter than either adding or removing the requirement that macros
can or cannot expand into DECLAREs.
Inertial of existing programs is a little harder to rate; it would also
seem reasonable for those with large quantities of MacLisp code such as
Macsyma might want to run in an (improper) superset which allows
"old-style" declares.
It would help,
∂17-May-85 0807 JLW EQUALP hash tables
To: Fahlman@CMU-CS-C.ARPA
CC: common-lisp@SU-AI.ARPA
In-reply-to: your message of 11-May-85 10:59 EDT
As for names for the "equivalence" and "numericalizing" functions for
hash tables, well, the :test argument is already the "equivalence" argument;
how about :sxhash for the numericalizing argument? This has the mnemonic
value that the default for it could simply be #'SXHASH.
I see no reason to restrict the possible values that :sxhash may have --
even when the :test argment is #'EQ; as my note last week was intending
to point out, EQ-type hash tables needn't be constrained to use pointer
bits for the :sxhash -- it's only a vague general feeling that we don't
want to have to re-hash whenever some object in th table is updated that
prevents use of #'SXHASH here. But for many (maybe even most?) applications
there is really no need to worry about the updating problem; after all,
who really worrys about it with EQUAL type tables? and it's just as
serious a problm there too, as Hoey pointed out.
How would you feel about this? The default :sxhash value will be an internal
version of MAKNUM *** when the :test arg is #'EQ o #'EQL *** rather than
SXHASH (appropriate conversions from 'EQ and 'EQL). iven this, is there any
need to have the user supply the information that the table will have to be
re-hash'd after a relocating GC? This condition should only occur when the
:sxhash function is somehow a function of the entry's pointer address -- and
by fiat you are ruling out any user-level function that returns that address.
Can anyone think of a case where this isn't true?
Finally, I'd say your suggestion for a REHASH function is quite timely.
Interlisp has such a function:
(REHASH hash-array new-array)
where both argments are hash-arrays, and the first one is merely re-hashed
into the second; a NIL for the second arg means something like (I think)
"cons up a fresh hash array just big enough to hold all the elements of
the first argument, and it's :rehash-threshold size"; and a T for the
second arg means something like (I think) "cons up a fresh hash array big
enough to be the growth by the :rehash-size of the first argument".
[well, if it doesn't operate exactly like that, it should].
A useful scenario is to make a huge hash table, make many entries over a
period of time, and then finally decide that not may more entries will
be made; thus one will want to "shrink" the table to the minimum feasible
size for holding the current entries. REHASH, as defined above, with a
second arg of NIL is just the right thing.
-- JonL --
∂17-May-85 0841 JLW hash table types
To: dcp%tenex.scrc@MIT-XX.ARPA
CC: common-lisp@SU-AI.ARPA
In-reply-to: your message of 12-May-85 10:56 EDT
Your list of "external things [I] see need changing" looks quite good
to me. I might add the suggestion that we add a ROT primitive to CL
which is machine independent. The following definition got added to
Interlisp shortly after I went to Xerox:
(ROT x n fieldsize)
"performs a bitwise left-rotation of the integer x, by n places, within
a field of fieldsize bits wide. Bits shifted out of the position selected
by (expt 2 (sub1 fieldsize)) will flow into the 'units' position."
Now, this definition has the advantage that on many machines, there will be
one particular field size for which the implementation of this ROT will be
very efficient (i.e., the one actually supported by a hardware ROT instruction).
And since SXHASH is permitted to be implemetation dependent -- not "address
dependent", but rather varying between one implementation and another -- then
each implementation can use a ROT in it's sxhash with a field size that is
efficient.
-- JonL --
∂17-May-85 0905 BSG@SCRC-STONY-BROOK.ARPA Poor excuse for packages
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85 08:38:26 PDT
Received: from SCRC-STONY-BROOK.ARPA (scrc-stony-brook.arpa.ARPA) by THINK.ARPA id AA05295; Fri, 17 May 85 11:27:52 edt
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 238638; Fri 17-May-85 11:28:13-EDT
Date: Fri, 17 May 85 11:24 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Poor excuse for packages
To: gls%AQUINAS@THINK.ARPA, common-lisp%sail@THINK.ARPA
In-Reply-To: <850517103227.1.GLS@DESIDERIUS.ARPA>
Message-Id: <850517112438.5.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Friday, 17 May 1985, 10:32-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
KMP hinted at a very interesting solution to the special-variables
problem: let symbols in the package SPECIAL name special variables,
and let all others name local variables. There doesn't seem to be
much wrong with
(LET ((SPECIAL:MY-GLOBAL-FLAG 43)
(SPECIAL:PRINT-PRETTY T))
...)
or
(DEFUN FOO (A B SPECIAL:C) ...)
It's cheap to detect, too, in interpreter or compiler: just check the
package cell. This I like. Too bad it's too late.
An ugly suggestion is to ADD this mechanism to the language without
removing the declaration syntax yet, and let people phase over during
the next year. Ugh, bletch.
There is a fairly major problem with this. "Suppose two applications
that have nothing to do with each other use the symbol SPECIAL:FOO".
I.e., everything that packages had bought you is now lost.
∂17-May-85 0905 KMP@SCRC-STONY-BROOK.ARPA Poor excuse for packages
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85 08:38:55 PDT
Received: from SCRC-STONY-BROOK.ARPA (scrc-stony-brook.arpa.ARPA) by THINK.ARPA id AA05313; Fri, 17 May 85 11:31:04 edt
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 238641; Fri 17-May-85 11:31:09-EDT
Date: Fri, 17 May 85 11:30 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Poor excuse for packages
To: gls%AQUINAS@THINK.ARPA, common-lisp%sail@THINK.ARPA
In-Reply-To: <850517103227.1.GLS@DESIDERIUS.ARPA>
Message-Id: <850517113027.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Friday, 17 May 1985, 10:32-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
KMP hinted at a very interesting solution to the special-variables
problem: let symbols in the package SPECIAL name special variables,
and let all others name local variables. There doesn't seem to be
much wrong with
(LET ((SPECIAL:MY-GLOBAL-FLAG 43)
(SPECIAL:PRINT-PRETTY T))
...)
or
(DEFUN FOO (A B SPECIAL:C) ...)
It's cheap to detect, too, in interpreter or compiler: just check the
package cell. This I like. Too bad it's too late.
An ugly suggestion is to ADD this mechanism to the language without
removing the declaration syntax yet, and let people phase over during
the next year. Ugh, bletch.
I certainly did not intend to hint at such a thing. While it might be
appropriate for a user program to put all its specials on one package and
all its non-specials on another, or even appropriate for it to be possible
for a whole package to somehow be declared to have implicitly special
variables (perhaps unless explicitly declared LEXICAL), it is not reasonable
to make every utility's specials share the same namespace!
Your suggestion is tantamount to saying that package information should be
ignored for variables and used only by EQ and function lookup since the package
of a lexical variable almost never matters -- ie, how many people do you
expect to write:
(DEFUN F (FOO:X BAR:X) (+ FOO:X BAR:X))
? On the other hand, you might well expect someone to write:
(DEFUN AVERAGE-LINEL () (// (+ FOO:*LINEL* BAR:*LINEL*) 2))
and certainly
(DEFUN AVERAGE-LINEL () (// (+ SPECIAL:*FOO-LINEL* SPECIAL:*BAR-LINEL*) 2))
would be a -real- step backward.
Adopting a solution like this would mean that programs written without
knowledge of each other might collide very badly when loaded into the same
environment for some application that wanted to compose them.
Clearly unacceptable.
∂17-May-85 0905 Cassels@SCRC-STONY-BROOK.ARPA Poor excuse for packages
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85 08:59:20 PDT
Received: from SCRC-STONY-BROOK.ARPA (scrc-stony-brook.arpa.ARPA) by THINK.ARPA id AA05491; Fri, 17 May 85 11:53:37 edt
Received: from CUYAHOGA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 238658; Fri 17-May-85 11:52:10-EDT
Date: Fri, 17 May 85 11:52 EDT
From: Robert A. Cassels <Cassels%TENEX.SCRC.Symbolics.COM@THINK.ARPA>
Subject: Poor excuse for packages
To: gls%AQUINAS@THINK.ARPA, common-lisp%sail@THINK.ARPA
In-Reply-To: <850517103227.1.GLS@DESIDERIUS.ARPA>
Message-Id: <850517115227.0.CASSELS@CUYAHOGA.SCRC.Symbolics.COM>
Date: Friday, 17 May 1985, 10:32-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
KMP hinted at a very interesting solution to the special-variables
problem: let symbols in the package SPECIAL name special variables,
and let all others name local variables. There doesn't seem to be
much wrong with
(LET ((SPECIAL:MY-GLOBAL-FLAG 43)
(SPECIAL:PRINT-PRETTY T))
...)
or
(DEFUN FOO (A B SPECIAL:C) ...)
Ack! What's the point of packages then? I thought they were for
avoiding name conflicts. Maybe you meant that some packages should be
declared as holding only special symbols. Then we could have
MY-SPECIAL:FOO and YOUR-SPECIAL:FOO. But this is getting silly.
I think a more interesting interpretation of KMP's idea is to have some
symbols which are always special. How they are marked internally is an
implementation detail. The problem from the language designer's point
of view is then to decide how the programmer specifies which of the
symbols he typed are special and which are not. Other places in the
language, we have used syntactic markers -- why not here? (YOW! Are we
Common SCHEME yet??)
The only similar thing in the present CL is the ":" vs. "::" syntax for
internal and external package symbols. So we probably want some sort of
prefix operator. Perhaps "*" as a leading character, since that would
break the smallest number of existing programs. Maybe *:FOO and
MY-PACKAGE*:FOO. Hopefully someone an come up with a better syntax.
It's cheap to detect, too, in interpreter or compiler: just check the
package cell. This I like. Too bad it's too late.
An ugly suggestion is to ADD this mechanism to the language without
removing the declaration syntax yet, and let people phase over during
the next year. Ugh, bletch.
∂17-May-85 0944 smh@mit-eddie.ARPA Re: Poor excuse for packages
Received: from MIT-EDDIE.ARPA by SU-AI.ARPA with TCP; 17 May 85 09:34:13 PDT
Received: by mit-eddie.ARPA (4.12/4.8) id AA27181; Fri, 17 May 85 12:33:48 edt
Date: Fri, 17 May 85 12:33:48 edt
From: Steven M. Haflich <smh@mit-eddie.ARPA>
Message-Id: <8505171633.AA27181@mit-eddie.ARPA>
To: common-lisp@sail
Subject: Re: Poor excuse for packages
Cc: gls%aquinas@think
> KMP hinted at a very interesting solution to the special-variables
> problem: let symbols in the package SPECIAL name special variables,
> and let all others name local variables.
But, but, then all specials are necessarily in the same package, and
we are back to the original problem that component subsystems cannot
ensure that their symbols will not clash with those of other
subsystems.
> It's cheap to detect, too, in interpreter or compiler: just check the
> package cell. This I like. Too bad it's too late.
This aspect is indeed nice! I think to do it right, each package
would implicitly be split into two components: one subpackage
containing the specials, and one the non-specials. (This use of
"subpackage" has nothing to do with the old LM notion of subpackage.)
The package name of the specials subpackage would be automatically
generated, perhaps by prepending `*'. By reader convention, *:foo
would be the special variable foo in the current package.
The implementation would be such that the subpackages necessarily
share the same inheritance structure; naming either subpackage in
intern, import, export, shadow, etc., would be equivalent, except for
the implication of variable specialness.
On the balance, I agree this idea is not worth the pain. However, its
consideration leads to an interesting question: Can anyone think of a
situation in which it is useful or even reasonable to refer to a
non-special variable using an explicit package qualifier?
∂17-May-85 0957 hoey@nrl-aic SXHASH and EQ hash tables
Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 17 May 85 09:53:46 PDT
Message-Id: <8505171652.AA09246@nrl-aic>
Date: 17 May 1985 12:08:27 EDT (Fri)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: SXHASH and EQ hash tables
To: Jon White <JLW@SU-AI.ARPA>
Cc: common-lisp@su-ai.ARPA
I agree that limiting the number of substructures visited by SXHASH is
a good thing to do. The next manual should promise that SXHASH will
operate on any object, and mention depth- and length-limiting as an
implementation note. Probably what you want is just a limit on the
number of substructures visited. There's probably no good way of
outlawing a constant function, but I think the desirability of having a
large range for SXHASH goes without saying.
Scott pointed out to me that efficiency rules out having (SETF (GETHASH
KEY ...)) do an automatic (COPY-TREE KEY) for the insertion. He
suggested removing the item from the hashtable, then modifying it, then
reinserting; that's a solution in some cases, but what if a lot of keys
share the modified structure? Well, for EQUAL hash tables, I think the
manual should mention that you might want to (SETF (GETHASH (COPY-TREE
Key)...)). And for EQUALP hashtables, there should be a
COPY-SUBSTRUCTURE (or COPY-TREE :TEST #'EQUALP ?) function to do the
analogous thing.
As for using SXHASH on EQ hash tables, I think this is a really bad
idea. There's just no way to get around rehashing, and I think it's
conceptually wrong to have to worry about it. I can see rehashing
``whenever some object in the table is updated'' but for EQ keys you
aren't modifying the object in the table. Here I think the manual
should promise that EQ hashing is insensitive to changes in
substructures.
Dan
∂17-May-85 0958 gls%AQUINAS@THINK.ARPA Poor excuse for a Quux
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85 09:58:16 PDT
Received: by THINK.ARPA with CHAOS id AA06628; Fri, 17 May 85 12:47:31 edt
Date: Friday, 17 May 1985, 12:48-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Poor excuse for a Quux
To: common-lisp@sail
Cc: gls%AQUINAS@THINK.ARPA
Message-Id: <850517124814.1.GLS@DESIDERIUS.ARPA>
Sigh. I figured out why the SPECIAL:FOO suggestion was totally wedged
about three seconds after I had mailed off my note. My apologies for
wasting everyone's time. (Apologies too to KMP for misrepresenting his
intentions.) I won't insult your intelligence by suggesting such
epicycles as
USER:SPECIAL:PRINT-PRETTY
and TV:SPECIAL:MOUSE-CURSOR-PATTERN
That's what I get for shooting from the hip.
∂17-May-85 0959 gls%AQUINAS@THINK.ARPA Backquote idioms
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85 09:58:42 PDT
Received: by THINK.ARPA with CHAOS id AA06920; Fri, 17 May 85 12:56:43 edt
Date: Friday, 17 May 1985, 12:57-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Backquote idioms
To: common-lisp@sail
Cc: gls%AQUINAS@THINK.ARPA
Message-Id: <850517125728.2.GLS@DESIDERIUS.ARPA>
Has anyone ever undertaken a study or catalog of backquote idioms?
Those of you who have used backquote at all seriously have probably come
to regard
', ,', ,, ,@, ,@', ,',',
as primitive idioms, almost recognizable as units, such as we take in CADDR
at a glance without thinking about the three component operations.
I raise this question because a few weeks ago I was confronted for the
first time with a situation for which the eventual solution was
,@(LIST ,@X)
and it occurred to me that ,@(LIST ,@ is another useful idiom.
(It is the splicing analogue[*] of ,, .)
Anyway, it would be interesting to assemble a list of such useful idioms.
It might make a good paper for the 1986 LISP conference. (Alan, are
you listening?)
--Guy
[*] I am aware that it is terribly inconsistent of me to write "catalog"
but "analogue". I promise not to do it again (very much).
∂17-May-85 1045 @MIT-REAGAN.ARPA:Soley@MIT-MC.ARPA Macros -> declarations
Received: from MIT-REAGAN.ARPA by SU-AI.ARPA with TCP; 17 May 85 10:30:23 PDT
Received: from MIT-CHERRY by MIT-REAGAN via CHAOS with CHAOS-MAIL id 4996; Fri 17-May-85 13:32:09-EDT
Date: Fri, 17 May 85 13:30 EDT
From: Soley@MIT-MC.ARPA
Subject: Macros -> declarations
To: Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850517092025.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <850517133012.1.SOLEY@CHERRY.MIT>
Date: Thu, 16 May 1985 22:45 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
We've kicked this idea around before in various forms, including the use
of some sort of syntactic marker on special bindings -- something like
turning FOO into $FOO if the variable is special, or treating the *FOO*
convention as being a declaration of specialness. Other lexical Lisps
have done this sort of thing with no obvious ill effects (and arguably
some good effects), but it seems to have been too radical a change to
have been seriously considered by most of the Common Lisp people when
the language was being designed.
Definitely, a great idea. But instead, why not just say that all
variables whose printnames start with the characters 'I' through 'N' are
special? A good extension to tried and true languages. :-)
-- Richard
∂17-May-85 1158 HEDRICK@RUTGERS.ARPA special declaration
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 17 May 85 11:56:57 PDT
Date: 17 May 85 14:55:49 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: special declaration
To: common-lisp@SU-AI.ARPA
As an implementor, I would be only too happy to flush the current
(incomplete) tests for SPECIAL declarations in favor of something
that is in the lambda list. The idea of using the pname is
obviously a bad one, but I don't see any problem with things
such as
(foo &special bar)
(foo (special bar))
(foo #$bar)
I would much prefer these to the current situation, and the sooner
the better... At the moment there probably isn't a large body of
CL code yet. It is just barely possible to make changes like this
now. Shortly it will not be practical. I assert that it is
possible to do a mechanical translation from the old to the new
form, particularly for implementations that don't yet handle
macros that expand to declarations. I have thought of one case
that this can't handle, but it is probably so pathological that
we can ignore it.
------------------------
Appendix. A pathlogical case.
In order to assure portability, it might be helpful to make sure
that code can run in implementations that use lexical binding
and in implementations that use dynamic binding. For this
purpose, we will declare all of our variables using the
macro SOMETIMES-SPECIAL. This will declare all of its arguments
special when the day of the month is odd, and otherwise expand
to NIL.
-------
∂17-May-85 1815 Moon@SCRC-STONY-BROOK.ARPA EQUALP hash tables (and more ...)
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 17 May 85 18:14:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239098; Fri 17-May-85 21:14:43-EDT
Date: Fri, 17 May 85 21:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: EQUALP hash tables (and more ...)
To: Common-Lisp@SU-AI.ARPA
Message-ID: <850517211410.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
DCP's message of 12 May said most of what I want to say on the subject of
generic hash tables, Symbolics' experience with them, and what issues are
involved in implementing them.
One other point: I suspect that rather than specifying the equivalence
function and the hashing function as separate arguments to
MAKE-HASH-TABLE, you would be better off introducing a DEFHASH special
form that defines a new flavor [sic] of hash table. That way, you
package up the equivalence function and the hashing function together
into something that has a name, and you don't have to face the issue of
inconsistent combinations. Furthermore, the DEFHASH for EQ and EQL hash
tables has already been done by the Common Lisp implementation, so you
don't have to publish the name of their implementation-dependent hashing
function.
Our CL implementation already uses the :TEST argument to MAKE-HASH-TABLE
as a key looked up in a table of flavors of hash table, but we haven't
told users how to add their own entries to that table.
∂17-May-85 1831 Moon@SCRC-STONY-BROOK.ARPA Macros -> declarations
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 17 May 85 18:31:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239102; Fri 17-May-85 21:30:58-EDT
Date: Fri, 17 May 85 21:30 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Macros -> declarations
To: common-lisp@SU-AI.ARPA
In-Reply-To: <850510015144.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<FAHLMAN.12109898307.BABYL@CMU-CS-C.ARPA>,
The message of 16 May 85 17:53-EDT from Masinter.pa@Xerox.ARPA,
<FAHLMAN.12111607133.BABYL@CMU-CS-C.ARPA>,
The message of 17 May 85 10:42-EDT from Masinter.pa@Xerox.ARPA,
The message of 17 May 85 14:55-EDT from Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Message-ID: <850517213026.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 10 May 85 01:51 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY (BODY '(...default body...))
(DECLS '((DECLARE (SPECIAL *FOO*))))
(DOC "a macro"))
...)
I believe that attacking the problem of DECLARE at the level people have been
attacking it gives up programmer flexibility to no good end (not to mention
introducing an incompatible change to the language semantics). A change
like these syntax extensions to DEFMACRO that I've been speaking about would
make life easy for the macro writer without giving up the macro-writing
freedoms I was originally supporting.
I think this is a good suggestion. Of course we ought to think about it a bit before
adopting it, but I haven't seen any problems of Common Lisp changing too fast lately!
Date: 16 May 85 14:53 PDT
From: Masinter.pa@Xerox.ARPA
The only reason for this issue is because the interpreter has to look
ahead for SPECIAL declarations. SPECIAL declarations are the only ones
that have any semantic import. Furthermore, SPECIAL declarations are the
only ones that are textually retroactive, in that they apply to things
that appeared BEFORE the declaration rather than after.
This last sentence is not true. Actually, there are almost no declarations
in Common Lisp that are -not- textually retroactive, because declarations
are placed in the -middle- of the form to which they apply.
Rather than hacking around the deficiencies of DECLARE, why not change
it? Put SPECIAL declarations where they belong, next to the variable.
Leave all the other declarations where they are. Most of these issues
then become moot, and we can even consider freeing up some of the
restrictions on declarations; it would seem reasonable to allow
declarations anywhere in an implicit PROGN to refer to the stuff that
follows.
I don't think it is only SPECIAL declarations that need to be attached to
variable bindings. Consider the data-type declarations.
One point I'd like to make in this connection is that making SPECIAL
declarations locally, rather than globally with DEFVAR, is generally not
something we should be encouraging. It's worth noting that the main use
of local SPECIAL declarations in Maclisp-like languages in the past has
been to simulate what FLET does better. Now that we have full lexical scoping,
we can probably dispense with local SPECIAL declarations.
Perhaps the SPECIAL declaration should be phased out, so we can say that
DECLARE never has "semantic import", but is only a hint to the compiler
or otherwise an "annotation." The SPECIAL proclamation would remain, of
course. If people feel it is necessary, some way to change the SPECIAL
status of a name locally could be retained, but it need not be DECLARE.
It could be a special [multiple puns intentional] version of LET.
This wouldn't change the fact that macro writers need a PARSE-BODY,
since losing an annotation that makes the code run efficiently is almost
as unacceptable as losing an annotation that makes the code run
correctly or one that documents the code.
Date: Thu, 16 May 1985 22:45 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Personally, I like the idea. I've felt for some time that we ought to
separate SPECIAL declarations from all the others, even if that means
that Common Lisp ends up looking a little different from Maclisp. But
we should only make this move so late in the game if just about everyone
else feels likewise.
Agreed.
Date: 17 May 85 14:55:49 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
As an implementor, I would be only too happy to flush the current
(incomplete) tests for SPECIAL declarations in favor of something
that is in the lambda list. The idea of using the pname is
obviously a bad one, but I don't see any problem with things
such as
(foo &special bar)
We haven't bothered to remove support for &SPECIAL from our system yet,
so we could hardly complain if it became a standard instead of an obsolete
holdover from the past! Again, though, I think there is little real need
for local SPECIAL declarations.
∂17-May-85 2051 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 May 85 20:50:57 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 17 May 85 23:50:21-EDT
Date: Fri, 17 May 1985 23:50 EDT
Message-ID: <FAHLMAN.12111881156.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 17 May 1985 21:30-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Now there's an idea: flush local SPECIAL declarations altogether,
keeping only global SPECIAL proclamations. I'll have to think about
this awhile to see if I really believe that we can do without these
declarations, but it is certainly a very attractive suggestion at first
glance. Can anyone think of a really important use for such
declarations?
I don't understand Moon's comment that local SPECIAL declarations have
mostly been used to simulate what FLET does better. Can you elaborate a
bit?
As Moon points out, even with this change we would still need PARSE-BODY
for macro writers, but it would sure make life easier for the
interpreter, since the other declarations can all be ignored unless
you're doing tense error-checking.
-- Scott
∂18-May-85 0815 KMP@SCRC-STONY-BROOK.ARPA Macros -> declarations
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 May 85 08:15:34 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239203; Sat 18-May-85 11:15:26-EDT
Date: Sat, 18 May 85 11:14 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Macros -> declarations
To: Fahlman@CMU-CS-C.ARPA, Moon@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12111881156.BABYL@CMU-CS-C.ARPA>
Message-ID: <850518111450.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Fri, 17 May 1985 23:50 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Now there's an idea: flush local SPECIAL declarations altogether,
keeping only global SPECIAL proclamations. I'll have to think about
this awhile to see if I really believe that we can do without these
declarations, but it is certainly a very attractive suggestion at first
glance. Can anyone think of a really important use for such
declarations?
I can provide a few from recent experience with Macsyma. I'm not sure they'll
convince you 100%, but hopefully they'll at least make you stop and think.
It largely depends on whether you consider the goal is to produce a language
that's clean and shiny or one that cares about things like compatibility with
the past where possible, etc. I think these goals conflict pretty badly. With
my language designer's hat on, I'd reject almost all of these arguments out of
hand. But since CL was designed by people prone to wear their politician's hats
a lot of the time, I'm of the impression that things like "compatibility with
the past" and such are likely to carry more weight, so here goes...
* Sometimes a function will need to be compiled "out of place" (eg,
before the relevant DEFVAR is loaded). In such cases, the problem
may go away if you move the definition containing the spurious
reference to another file (which is processed after the DEFVAR),
but the SPECIAL declaration may linger.
* In any large system which is being converted incrementally from some other
Lisp dialect (eg, old Maclisp or a relative, Interlisp, ...), it may be
desirable to incrementally convert the semantics of variables used by
functions. Using local SPECIAL declarations, you can gradually whittle away
the region in which certain specials are used. If you force global SPECIAL
declarations, you undermine the ability to make such transitions incrementally.
* Although Macsyma is being converted for Common Lisp, it may continue to run
in other dialects of Lisp as well. As such, FLET and friends may not be
available in those dialects and a number of situations may arise where
local SPECIAL declarations provide a way of achieving compatibility with
those otherwise-not-cooperating dialects.
* There are numerous examples of special variables being used as
communication between three or four definitions. We've been working on
converting:
(DECLARE (SPECIAL X))
(DEFUN FOO () ... refers to special X ...)
(DEFUN BAR () ... refers to special X ...)
(DECLARE (UNSPECIAL X))
into
(DEFUN FOO () (DECLARE (SPECIAL X)) ... refers to special X ...)
(DEFUN BAR () (DECLARE (SPECIAL X)) ... refers to special X ...)
This a couple of advantages worth noting.
* Common Lisp has no UNSPECIAL declaration (that I could find).
If the special is a common name like X, we need to not have every
reference to X compiled SPECIAL. It may be very expensive and
dangerous (ie, in terms of potential for typos, timing errors, etc)
to change all 180 source files for Macsyma to use names that could
reasonably be left SPECIAL all the time. (At some point we may
consider this, but...)
* It makes it explicit when you look at a particular definition
just how the communication is being done (since mostly these variables
don't have *...* around them.
* It is a -very- common problem that we will modify a definition
and just put that definition in a patch file, only to find it compiles
differently out of context because the appropriate SPECIAL declarations
were not present. Having the SPECIAL declarations in the definition
means they will move with the definition into the patch file. (This
problem would be "solved" by making SPECIAL declarations global and
outlawing UNSPECIAL, but would mean I'd have to rename an awful lot of
variables, which I mentioned above is a bit scary...)
----Fahlman:
I don't understand Moon's comment that local SPECIAL declarations have
mostly been used to simulate what FLET does better. Can you elaborate a
bit?
I assume he meant that variables which must be accessed in downward funargs
(eg, to MAPCAR and user-defined friends) no longer have to be passed special.
Likewise, what people used to write as:
(DEFUN IN (OBJ TREE) (DECLARE (SPECIAL OBJ)) (IN1 TREE))
(DEFUN IN1 ()
(DECLARE (SPECIAL OBJ))
(COND ((ATOM TREE) (EQ OBJ TREE))
(T (OR (IN1 (CAR TREE)) (IN1 (CDR TREE))))))
can now be written:
(DEFUN IN (OBJ TREE)
(LABELS ((IN1 (TREE)
(COND ((ATOM TREE) (EQ OBJ TREE))
(T (OR (IN1 (CAR TREE)) (IN1 (CDR TREE)))))))
(IN1 TREE)))
----Fahlman:
As Moon points out, even with this change we would still need PARSE-BODY
for macro writers,
or my &BODY hack. No sense in not providing both, though.
but it would sure make life easier for the interpreter, since the other
declarations can all be ignored unless you're doing tense error-checking.
∂18-May-85 0932 masinter.PA@Xerox.ARPA uses for specials
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 18 May 85 09:32:35 PDT
Received: from Riesling.ms by ArpaGateway.ms ; 18 MAY 85 09:32:17 PDT
From: masinter.PA@Xerox.ARPA
Date: 18 May 85 9:30:27 PDT
Subject: uses for specials
To: common-lisp@su-ai.ARPA
I've seen more than one program that constructs expressions on the fly,
and then EVALs them in another context.
PROGV has an implicit local special declaration.
As long as an incompatible name is being considered, how about changing
the name? While there's some amusement in having SPECIAL a special form,
the novice may well wonder, "well, what's so SPECIAL about them?". Guy
was careful to call them DYNAMIC in the book; it sounds like a more
appropriate name for a (different syntax) declaration.
∂18-May-85 1112 KMP@SCRC-STONY-BROOK.ARPA DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form"
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 May 85 11:11:50 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239223; Sat 18-May-85 14:11:42-EDT
Date: Sat, 18 May 85 14:11 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form"
To: masinter.PA@XEROX.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 18 May 85 12:30-EDT from masinter.PA@XEROX.ARPA
Message-ID: <850518141104.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 18 May 85 9:30:27 PDT
From: masinter.PA@Xerox.ARPA
... As long as an incompatible name is being considered, how about changing
the name? While there's some amusement in having SPECIAL a special form,
the novice may well wonder, "well, what's so SPECIAL about them?". Guy
was careful to call them DYNAMIC in the book; it sounds like a more
appropriate name for a (different syntax) declaration.
-- DYNAMIC/LEXICAL --
It would seem reasonable that CL86 should add DYNAMIC as a synonym for SPECIAL
in the declaration world, and LEXICAL for symmetry. Then in CL88 could flush
SPECIAL (or make it mean something incompatible).
-- *LEXPR --
Can we get a ruling on whether
(FUNCTION (FOO INTEGER &OPTIONAL INTEGER))
is a valid declaration? p159 is very vague on the subject, giving no syntax
restrictions for the arglist components at all. (Only through the limited
fixed-arg example can you even infer that the arglist given should contain
type names and not be the actual arglist used by the function.)
The compiler should be encouraged to complain if it sees
(PROCLAIM '(FUNCTION FOO INTEGER &OPTIONAL INTEGER))
and later sees
(DEFUN FOO (X)
(DECLARE (SYMBOL X))
...)
but should be discouraged from complaining (or should at least be encouraged
to notice the non-fatal nature of the situation) if it later sees:
(DEFUN FOO (X &OPTIONAL (Y 1) (Z 2))
(DECLARE (INTEGER X Y Z))
...)
since in the latter case, the definition is upward compatible with the
declaration.
It occurred to me that without &OPTIONAL working in FUNCTION declarations,
the functionality of Maclisp's *LEXPR declaration is conspicuously absent.
By the way, apropos of Masinter's comments above, and given that it's useful
to declare something like takes-variable-number-of-args in advance to thwart
forward-referencing problems, it might also want to be possible to declare
that some form, WITH-RANDOM-BINDINGS, is a special form so that
forward-references (which will tend to be fatal errors) to it can be
diagnosed immediately rather than having to wait for the definition to roll
by. I assume this is what he was alluding to about it might have been
more appopriate for syntax declarations, as in
(PROCLAIM '(SPECIAL WITH-RANDOM-BINDINGS)).
I guess it's a little late to try to make such a change in CL84, much less
CL86. Maybe CL88...
-- "Special Operator" vs "Special Form" --
Also, I'd like to replace the term "special form" with "special operator"
when it doesn't apply to the whole form. ie, COND is not a special form,
it is a special operator (properly, it's the name of a special operator
but that's not so critical to me at this point). Certainly,
(COND ((NULL X) T) (T NIL)) is a "special form" and COND is not of the
same type so needs its own name. I would like to see SPECIAL-FORM-P made
obsolete (but retained for a while for compatibility) and SPECIAL-OPERATOR-P
introduced as an alternative. In this way, SPECIAL-FORM-P could eventually
be recycled (or flushed from CL proper and re-invented by private applications
that care) to be (AND (TYPEP x 'CONS) (SPECIAL-OPERATOR-P (CAR x))). Actually,
having the interim compatibility definition be
(OR (SPECIAL-OPERATOR-P x)
(AND (TYPEP x 'CONS) (SPECIAL-OPERATOR-P (CAR x))))
wouldn't be so bad either if we could agree to that. That way, people who
order their COND clauses correctly, could start taking advantage of the
recycled meaning right away. In any case, the important point here is that
the "form" / "operator" distinction needs to be made more clearly than we've
been making it.
∂18-May-85 1156 WHOLEY@CMU-CS-C.ARPA Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 May 85 11:56:31 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Sat 18 May 85 14:56:12-EDT
Date: Sat, 18 May 1985 14:56 EDT
Message-ID: <WHOLEY.12112046053.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA, Fahlman@CMU-CS-C.ARPA, Moon@SCRC-STONY-BROOK.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 18 May 1985 11:14-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Date: Saturday, 18 May 1985 11:14-EDT
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Date: Fri, 17 May 1985 23:50 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
As Moon points out, even with this change we would still need
PARSE-BODY for macro writers,
or my &BODY hack. No sense in not providing both, though.
I think that PARSE-BODY is needed even if the &BODY hack is used. People other
than DEFMACRO (the mythical code analysis tools, for example) should have some
convenient way to parse bodies. Also, providing such a hook and encouraging
everyone to use it could make users' lives easier when and if the language
changed in any radical way.
On the other hand, the fancy &BODY syntax is a great win, and should be in the
language as well.
--Skef
∂18-May-85 1352 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 May 85 13:52:02 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 18 May 85 16:51:38-EDT
Date: Sat, 18 May 1985 16:51 EDT
Message-ID: <FAHLMAN.12112067060.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 18 May 1985 11:14-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Here's where my thinking is right now on all of this declaration stuff.
1. If it were up to me, I would still flush macro-to-definition
expansion, not because it is TOTALLY worthless but because the hassle it
causes far outweighs the marginal benefits. However, I am willing to
concede that this battle is lost, and that this misfeature will stay in
the language.
2. Given that, we definitely need PARSE-BODY as an official part of the
language, and some advice on its use in the chapter on Macros (or
someplace). The arguments would be (form environment &optional
(doc-string-allowed t)). Query: when this form returns a body, is it
desirable to allow it to return a cons of the macro-expanded first form
and the rest of the body, or should we require the original body to be
returned? Returning the expanded first form might sometimes save some
work, but I suppose you have to worry about things where some
optional-argument init code changes something that would alter the
macro-expansion.
3. I also think we should add KMP's extended syntax for &body, since
that makes it possible for Macro writers to pick apart these things
without having to explictly handle environments or even multiple values.
I prefer the simple syntax for this, as in (...&body (body decl doc)),
since it is less visually confusing (fewer nested parens) than the
version with defaults, and since I see no real use for these defaults.
But I could live with the more complex version, I guess.
4. We should give very serious consideration to eliminating local
special declarations. We would add DYNAMIC and LEXICAL proclamations,
and phase out the use of the term "special variable" and the SPECIAL
proclamation. (These would be changed in the 1986 manual, with a note
that this change has been made and advice that implementors handle the
phase-out gradually and carefully.) There would be some style advice
that DYNAMIC variables should generally be dynamic thoughout a whole
program and should observe the *foo* convention. The ability to switch
a variable back and forth from DYNAMIC to LEXICAL is provided mostly to
allow old code to be more easily ported to Common Lisp. We might
possibly need something like the SPECIAL-LET that Moon suggested -- I'm
not sure.
In answer to KMP's comments about the usefulness of special declarations
in porting old code:
Yes, clean language design and compatibility are natural enemies, as
most of us in this effort have seen many times. Any one of us could
have designed a better Lisp if compatibility were not an issue. On the
other hand, we explicitly decided that we would not shoot for full upward
compatibility with Maclisp or even for fully automatic translatability.
Some things were just too ugly not to change.
My own view of how compatible we want to be goes more or less as
follows: it should be possible to translate a program like Macsyma into
Common Lisp by having some competent programmer make a careful pass
through the code. If there are things that just don't translate in any
reasonable way (leaving aside some of the godawful PDP-10 hacks that
occur at low levels in Macsyma), then we have diverged too far. But we
should not feel constrained to have macsyma run in Common Lisp without a
conversion effort, and we certainly shouldn't feel constrained by a
desire to have the same source code run in other dialects of Lisp.
Of the specific problems that KMP raises, mostly having to do with
wanting to do big conversions a little bit at a time, I think that most
of these problems go away if we provide both DYNAMIC and LEXICAL
declarations. I recognize that it is sometimes convenient to have such
declarations lexically bundled into the function definitions they
modify, but I see no reason why the proclamations and the definitions
can't be moved into a patch file together, as though they were
surrounded by one set of outer parens. If you really care, there's
always PROGN to bundle these top-level forms together. I think that
this would handle Masinter's objection, about passing a form from one
environment to another, as well.
Finally, on BSG's suggestion for extensions to the macro syntax, so that
we can macro-expand different types of forms in different namespaces.
Right now we've only got two such contexts, normal evaluated forms and
type declarations. There was a proposal for a third type of context,
declaration subforms, but if we retain the Macro->declaration lossage it is
not necessary to add this. I see no need to go to a more general
mechanism to combine the two existing uses of macro-like expansion. I
also feel that if we do make this generalization, the pressure to
macro-expand new and bizarre kinds of things will increase over time.
SO I think we should table BSG's suggestion until such time as there is
a real need for it.
I've dumped all this stuff at once since I'm going to be off the net for
two weeks starting Monday.
-- Scott
∂18-May-85 1406 FAHLMAN@CMU-CS-C.ARPA DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form"
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 May 85 14:06:19 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 18 May 85 17:05:50-EDT
Date: Sat, 18 May 1985 17:05 EDT
Message-ID: <FAHLMAN.12112069635.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form"
In-reply-to: Msg of 18 May 1985 14:11-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
By the way, apropos of Masinter's comments above, and given that it's useful
to declare something like takes-variable-number-of-args in advance to thwart
forward-referencing problems, it might also want to be possible to declare
that some form, WITH-RANDOM-BINDINGS, is a special form so that
forward-references (which will tend to be fatal errors) to it can be
diagnosed immediately rather than having to wait for the definition to roll
by. I assume this is what he was alluding to about it might have been
more appopriate for syntax declarations, as in
(PROCLAIM '(SPECIAL WITH-RANDOM-BINDINGS)).
I guess it's a little late to try to make such a change in CL84, much less
CL86. Maybe CL88...
I don't understand this at all. Are you asking for a way for users to
declare that some user-defined form is a special form? There aren't
supposed to be any user-defined special forms.
-- "Special Operator" vs "Special Form" --
Also, I'd like to replace the term "special form" with "special operator"
when it doesn't apply to the whole form. ie, COND is not a special form,
it is a special operator (properly, it's the name of a special operator
but that's not so critical to me at this point).
Well, I've already used up my quota of ridicule for the month, so I'll
just say that this looks to me like nit-picking and I would oppose any
change to the name of a function in order to remove the alleged
inconsistency in the nomenclature. Name changes are always more hassle
than they should be, so they should only be done when the old name was
actually confusing people.
-- Scott
∂18-May-85 1413 FAHLMAN@CMU-CS-C.ARPA Macros -> declarations (oops!)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 May 85 14:13:36 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 18 May 85 17:13:22-EDT
Date: Sat, 18 May 1985 17:13 EDT
Message-ID: <FAHLMAN.12112071020.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Macros -> declarations (oops!)
In-reply-to: Msg of 18 May 1985 16:51-EDT from Scott E. Fahlman <Fahlman>
In my previous message, next to last paragrpah, I referred to providing
DYNAMIC and LEXICAL "declarations" a couple of times when I meant to say
"proclamations". To clarify, the proposal is that there would be no
DYNAIMC and LEXICAL declarations. Sigh!
-- Scott
∂18-May-85 1916 GSB@MIT-MC Re: EQUALP hash tables (and more ...)
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 May 85 19:14:28 PDT
Date: Sat, 18 May 85 22:15:14 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: Re: EQUALP hash tables (and more ...)
To: Common-Lisp@SU-AI
Message-ID: <[MIT-MC].509855.850518.GSB>
Date: Fri, 17 May 85 21:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
. . .
One other point: I suspect that rather than specifying the equivalence
function and the hashing function as separate arguments to
MAKE-HASH-TABLE, you would be better off introducing a DEFHASH special
form that defines a new flavor [sic] of hash table. That way, you
package up the equivalence function and the hashing function together
into something that has a name, and you don't have to face the issue of
inconsistent combinations. Furthermore, the DEFHASH for EQ and EQL hash
tables has already been done by the Common Lisp implementation, so you
don't have to publish the name of their implementation-dependent hashing
function.
Yes.
Our CL implementation already uses the :TEST argument to MAKE-HASH-TABLE
as a key looked up in a table of flavors of hash table, but we haven't
told users how to add their own entries to that table.
NIL does likewise. One of the "flavors" of hash table is
functional-hash-table, which is additionally parameterizable by a
function to do error checking on the key (so that it gets caught at
gethash level rather than by the equality or hashing function). There
is also some hair so that the equality function used can be different
from the name used to reference; e.g., hash-tables which use :TEST
#'STRING-EQUAL (one of the hash table tests predefined in NIL)
actually use an internal two-argument-only form of string-equal which
doesn't check its arguments, rather than applying the hairy one which
takes keyworded arguments. All NIL hash tables other than EQ and EQL
are implemented through this (string=, char-equal, string-equal and
equal are predefined).
∂19-May-85 0926 Gall.HIS←Guest@MIT-MULTICS.ARPA Re: DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 19 May 85 09:25:44 PDT
Posted-Date: 19 May 85 12:03 EDT
Date: Sun, 19 May 85 12:01 EDT
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: Re: DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special
Form"
To: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 18 May 85 14:11 EDT from "Kent M Pitman"
Message-ID: <850519160157.528715@MIT-MULTICS.ARPA>
Date: 18 May 1985 14:11 edt
From: Kent M Pitman <KMP at SCRC-STONY-BROOK>
Subject: DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special
Form"
Date: 18 May 85 9:30:27 PDT
From: masinter.PA@Xerox.ARPA
... As long as an incompatible name is being considered, how about changing
the name? While there's some amusement in having SPECIAL a special form,
the novice may well wonder, "well, what's so SPECIAL about them?". Guy
was careful to call them DYNAMIC in the book; it sounds like a more
appropriate name for a (different syntax) declaration.
-- DYNAMIC/LEXICAL --
It would seem reasonable that CL86 should add DYNAMIC as a synonym for SPECIAL
in the declaration world, and LEXICAL for symmetry. Then in CL88 could flush
SPECIAL (or make it mean something incompatible).
Yes.
-- *LEXPR --
Can we get a ruling on whether
(FUNCTION (FOO INTEGER &OPTIONAL INTEGER))
is a valid declaration? p159 is very vague on the subject, giving no syntax
restrictions for the arglist components at all. (Only through the limited
fixed-arg example can you even infer that the arglist given should contain
type names and not be the actual arglist used by the function.)
First, there is an error in the equivalence between the FUNCTION and
FTYPE decl. specifiers. The equivalence should be:
(FUNCTION name arglist result-type-1 result-type-2 ...)
<=> (FTYPE (FUNCTION arglist (VALUES result-type-1 result-type-2 ...)) name)
Secondly, the definition of `arglist' appears on pg. 47 in the def. of
the FUNCTION type specifier.
Two suggestions for the FUNCTION type-specifier definition. (1) Change
the word "markers" to "lambda-list keywords". (2) Define how a keyword
and its type are associated. For example, if I have a function that
takes a keyword argument named FOO of type INTEGER, I assume the type
specifier would look like this: (FUNCTION (&KEY (FOO INTEGER)) ...).
Also, take a look at the VALUES type-specifier on the next page. I was
surprised to see that it also allows lambda-list keywords (albeit for a
reason that confuses me). Could someone give an example of the
usefulness of this?
The compiler should be encouraged to complain if it sees
(PROCLAIM '(FUNCTION FOO INTEGER &OPTIONAL INTEGER))
and later sees
(DEFUN FOO (X)
(DECLARE (SYMBOL X))
...)
but should be discouraged from complaining (or should at least be encouraged
to notice the non-fatal nature of the situation) if it later sees:
(DEFUN FOO (X &OPTIONAL (Y 1) (Z 2))
(DECLARE (INTEGER X Y Z))
...)
since in the latter case, the definition is upward compatible with the
declaration.
Again I am confused. Is the following legal?
(PROCLAIM '(FUNCTION FOO INTEGER &OPTIONAL INTEGER))
(DEFUN FOO (ARG1)
(DECLARE (INTEGER ARG1))
...)
I.E., Is downward compatibility allowed also? If not, then perhaps the
upward compatibility case should not be legal. If downwardly compatible
definitions ARE allowed, then to make a proclamation that allows
upwardly compat. definitions one should proclaim
(PROCLAIM '(FUNCTION FOO INTEGER &OPTIONAL INTEGER &REST LIST))
This would allow any number of additional optional arguments.
My guess is that neither are legal and that the arglist in the FUNCTION
type-specifier must exactly match its corresponding lambda-list.
It occurred to me that without &OPTIONAL working in FUNCTION declarations,
the functionality of Maclisp's *LEXPR declaration is conspicuously absent.
By the way, apropos of Masinter's comments above, and given that it's useful
to declare something like takes-variable-number-of-args in advance to thwart
forward-referencing problems, it might also want to be possible to declare
that some form, WITH-RANDOM-BINDINGS, is a special form so that
forward-references (which will tend to be fatal errors) to it can be
diagnosed immediately rather than having to wait for the definition to roll
by. I assume this is what he was alluding to about it might have been
more appopriate for syntax declarations, as in
(PROCLAIM '(SPECIAL WITH-RANDOM-BINDINGS)).
I guess it's a little late to try to make such a change in CL84, much less
CL86. Maybe CL88...
I agree with Scott's comment. In CL, there's no such thing as a
special-form that the compiler and interpreter don't know about.
-- "Special Operator" vs "Special Form" --
Also, I'd like to replace the term "special form" with "special operator"
when it doesn't apply to the whole form. ie, COND is not a special form,
it is a special operator (properly, it's the name of a special operator
but that's not so critical to me at this point). Certainly,
(COND ((NULL X) T) (T NIL)) is a "special form" and COND is not of the
same type so needs its own name. I would like to see SPECIAL-FORM-P made
obsolete (but retained for a while for compatibility) and SPECIAL-OPERATOR-P
introduced as an alternative. In this way, SPECIAL-FORM-P could eventually
be recycled (or flushed from CL proper and re-invented by private applications
that care) to be (AND (TYPEP x 'CONS) (SPECIAL-OPERATOR-P (CAR x))). Actually,
having the interim compatibility definition be
(OR (SPECIAL-OPERATOR-P x)
(AND (TYPEP x 'CONS) (SPECIAL-OPERATOR-P (CAR x))))
wouldn't be so bad either if we could agree to that. That way, people who
order their COND clauses correctly, could start taking advantage of the
recycled meaning right away. In any case, the important point here is that
the "form" / "operator" distinction needs to be made more clearly than we've
been making it.
Yes. I think its at least worth mentioning in the section on special
forms that calling the symbol COND a `special-form' is a misnomer;
precisely speaking it is the name of a special form. This kind of
clarification is done for other `muddy' terms in CL, e.g., DYNAMIC,
UNBOUND.
∂19-May-85 0930 DD60@CMU-CS-A.ARPA user hash tables
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 19 May 85 09:29:59 PDT
Date: Sun, 19 May 85 12:28 EDT
From: David.Dill@CMU-CS-A.ARPA (L170DD60)
To: common-lisp@SU-AI.ARPA
Subject: user hash tables
Message-Id: <19May85.122856.DD60@CMU-CS-A.ARPA>
I have needed these badly. I have two suggestions:
I frequently want to store objects that have their retrieval keys in them
already; for example, a structure representing a symbol in a table often
has the string for the symbol sitting in the structure already for various
reasons. It is pointlessly inefficient to represent this in the hash
table as a pair (key . thing) when the thing contains the key already.
What you need here is a set implemented as a hash table, where the
definition of equality does comparison on some piece of the structure
of the object stored in the table, while hash tables as currently
designed are obviously intended to be like association lists. If a hash
set could be created with user-supplied :hash and :equality routines,
it would be very easy to do this. I believe that a hashed set
abstraction is also useful in its own right.
Now, in the example of a symbol table it is often the case that you
have a string in hand, and you want to find out if it is already in
the symbol table. If it is, you do nothing; if not, you want to create
a symbol structure with various auxilliary fields and store it in the
table. Hash sets as proposed above can be extended to do this very nicely
by adding a :insert routine, which is called when something is added
("adjoined", I guess) to the table. In this example, the insert routine
would take the string and table as an argument and create the symbol
table structure just before stuffing into the appropriate hash bucket.
Given hash sets in this form, it would be very easy to implement hash
tables by having the insert routine cons up a (key . object) pair.
(Actually, a lookup would return the pair and I don't remember whether
CL hash tables return this or the object.)
I have used a hash set implementation like this at CMU on the PQCC
project and at Tartan Labs (the :insert routine idea was John Nestor's).
Tables of this form don't quite do everything: sometimes I have wanted the
key to be a combination of several fields of the structure being stored
(say "name" field and "type" or "package"). I suppose the routines could
be extended to take &REST arguments or whatever.
One of the properties I usually want from a hash table is speed. Pulling
hash and equality routines out of a hash table object and calling them
is obviously going to add a fair amount of overhead to the whole process.
It would be nice if users could define a new type of hash table by
some method similar to DEFSTRUCT, and have these routines defined as
macros that could be expanded at compile time (but please don't suggest
hairing up DEFSTRUCT even more to do this!).
∂19-May-85 1246 FAHLMAN@CMU-CS-C.ARPA Yellow pages
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 May 85 12:46:28 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 19 May 85 15:46:18-EDT
Date: Sun, 19 May 1985 15:46 EDT
Message-ID: <FAHLMAN.12112317328.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Yellow pages
I have copied our local Spice Lisp program library to macine
CMU-CS-C.ARPA, from which it should be easily accessible by FTP. The
directory is PRVA:<SLISP.LIBRARY>, and the file CATALOG.TXT describes
the various programs in the library in a format that should be farily
easy for future "librarian" programs to use. The master copy is still
on CMU-CS-SPICE, but we'll try to keep the two directories in sync. RPG
may also move a copy to SU-AI.
This is just a beginning, of course. Some of the programs in this
library are in somewhat ragged shape, and most of them are dependent on
the Spice/Accent enviornment in some way. We hope to add some
additional stuff to this library as the summer progresses, including
OPS5 and Flavors. We will also be putting some effort into polishing
these things up and separating the truly portable things from the
non-portable ones.
For now at least, we reserve the right to change or improve these files
in incompatible ways any time we want to. If you want a stable copy of
something, grab your own copy.
If anyone else has contributions for this library, please let me know.
If you take one of these modules and significantly improve it, please
notify both the maintainer listed in the catalog file and me, and we'll
try to fold your improvements into the library version in a coherent
way. For now, we will only put things into the library that are public
domain or for which we have been granted permission to redistribute the
work without restriction.
No, we are not prepared to mail anyone a tape of this stuff. It is
changing too fast for that to be a worthwhile pursuit.
-- Scott
∂20-May-85 0707 DCP@SCRC-STONY-BROOK.ARPA Macros -> declarations
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 May 85 07:05:40 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239627; Mon 20-May-85 10:03:52-EDT
Date: Mon, 20 May 85 10:04 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Macros -> declarations
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>,
Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12112067060.BABYL@CMU-CS-C.ARPA>
Message-ID: <850520100457.9.NFEP@NEPONSET.SCRC.Symbolics.COM>
Suppose: We flush Macros -> declarations.
Question: Is the compiler allowed to do arbitrary and repetitive
("destructive") macro expansion at any time? By "destructive", I don't
necessarily mean RPLACA, I mean that the compiler then operates on the
expanded expressions?
If the answer is 'No' I suggest CLtL explains WHEN the compiler IS
allowed to expand macros.
If the answer is 'Yes' then I don't see how it is possible to flush
macro calls expanding into declarations. In this case, the
implementation of the compiler, NOT THE DEFINITION OF LANGUAGE, will
determine the semantics of the macro. A compiler that pre-expanded all
forms and subforms before "compiling" it would get the declarations that
were the result of macro expansion. (As a side effect, the compiler
would be guarenteed it wouldn't have to do macro expansion during
"compiling".) A compiler that expanded outermost expressions as it got
to them would not see the declarations which came from macros.
An alternative, which I mention just for completeness and is so vile I'm
glad I'm not prone to vomiting, is to kludge the automatic macro
expansion facility to know when declarations are possible and not to
expand macros it sees in those places (or maybe expand the macros but
wrap a PROGN around it).
∂20-May-85 0721 DCP@SCRC-STONY-BROOK.ARPA hash table types
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 May 85 07:21:04 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239648; Mon 20-May-85 10:11:10-EDT
Date: Mon, 20 May 85 10:12 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: hash table types
To: Jon White <JLW@SU-AI.ARPA>, dcp@TENEX
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 17 May 85 11:41-EDT from Jon White <JLW@SU-AI.ARPA>
Message-ID: <850520101218.0.NFEP@NEPONSET.SCRC.Symbolics.COM>
Date: 17 May 85 0841 PDT
From: Jon White <JLW@SU-AI.ARPA>
Your list of "external things [I] see need changing" looks quite good
to me. I might add the suggestion that we add a ROT primitive to CL
which is machine independent. The following definition got added to
Interlisp shortly after I went to Xerox:
(ROT x n fieldsize)
"performs a bitwise left-rotation of the integer x, by n places, within
a field of fieldsize bits wide. Bits shifted out of the position selected
by (expt 2 (sub1 fieldsize)) will flow into the 'units' position."
Now, this definition has the advantage that on many machines, there will be
one particular field size for which the implementation of this ROT will be
very efficient (i.e., the one actually supported by a hardware ROT instruction).
And since SXHASH is permitted to be implemetation dependent -- not "address
dependent", but rather varying between one implementation and another -- then
each implementation can use a ROT in it's sxhash with a field size that is
efficient.
I wouldn't object to this, but a refinement is necessary. Is ROT
supposed to give the same answer in all implementations? On two's
complement machines, (rot 1 (1- n) n) where N is the word width is
(probably) MOST-NEGATIVE-FIXNUM. Also, (rot 1 (1- n) n) == (ash -1 (1- n)).
In other words, ROT should imply sign extension (on two's complement
machines).
∂20-May-85 1012 gls%AQUINAS@THINK.ARPA Backquote idioms
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 20 May 85 10:12:15 PDT
Received: by THINK.ARPA with CHAOS id AA25172; Mon, 20 May 85 13:02:45 edt
Date: Monday, 20 May 1985, 13:03-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Backquote idioms
To: Common-lisp%sail@THINK.ARPA
Cc: gls%AQUINAS@THINK.ARPA
In-Reply-To: The message of 20 May 85 11:42-EDT from Mail Delivery Subsystem <MAILER-DAEMON at GODOT>
Message-Id: <850520130325.6.GLS@DESIDERIUS.ARPA>
Date: Fri, 17 May 85 20:44:49 EST
From: Jonathan A Rees <JAR@MIT-MC@think>
Subject: Backquote idioms
To: gls%AQUINAS@THINK
And consider the useful but not CL-supported ,,@ .
Much to my surprise, I find that
(a) ,,@ *is* supported by Common Lisp.
(b) ,,@ is equivalent to ,@(list ,@
I obtained these results by working through the expansions of
`(foo `(bar ,,@x))
and `(foo `(bar ,@(list ,@x)))
using the rules on pages 349-350 of the CLM.
--Guy
∂20-May-85 1328 KMP@SCRC-VALLECITO.ARPA "Special Operator" vs "Special Form"
Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 20 May 85 13:28:17 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 14082; Mon 20-May-85 16:28:29-EDT
Date: Mon, 20 May 85 16:28 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: "Special Operator" vs "Special Form"
To: Fahlman@CMU-CS-C.ARPA
cc: KMP@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12112069635.BABYL@CMU-CS-C.ARPA>
Message-ID: <850520162811.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Sat, 18 May 1985 17:05 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Date: 18 May 1985 14:11-EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
By the way, apropos of Masinter's comments ... I assume this is what he
was alluding to about it might have been more appopriate for syntax
declarations, as in
(PROCLAIM '(SPECIAL WITH-RANDOM-BINDINGS)).
I guess it's a little late to try to make such a change in CL84, much less
CL86. Maybe CL88...
I don't understand this at all. Are you asking for a way for users to
declare that some user-defined form is a special form? There aren't
supposed to be any user-defined special forms.
Sorry, I still get special and macro confused. In my Special Forms paper in
the 1980 lisp conference, I defined macros to be a subset of special forms.
Somewhere along the line, someone has taken it upon himself to change the
terminology and I haven't completely debugged things. Well, (PROCLAIM '(SPECIAL ...))
could still be meaningful, just not useful. I guess I was really thinking
(PROCLAIM '(MACRO ...)), though. In any case, I wasn't meaning to propose
anything; was mostly just making an observation.
I'm glad you agree that precise terminology on these things is important, though,
because that brings me neatly into the other point...
-- "Special Operator" vs "Special Form" --
Also, I'd like to replace the term "special form" with "special operator"
when it doesn't apply to the whole form. ie, COND is not a special form,
it is a special operator (properly, it's the name of a special operator
but that's not so critical to me at this point).
Well, I've already used up my quota of ridicule for the month, so I'll
just say that this looks to me like nit-picking and I would oppose any
change to the name of a function in order to remove the alleged
inconsistency in the nomenclature. Name changes are always more hassle
than they should be, so they should only be done when the old name was
actually confusing people.
My experience with teaching novices is that things work better when important
terms like these work better when used very consistently, and I really believe
people are probably being confused by this. I consider the issue of consistent
naming to be extremely important during the "formative years" of programmers
learning a new language. I think it sufficiently important to be worth weathering
the hassle of a name-change, though as I said I'm willing to all that name change
to happen in two steps over several years if necessary.
∂20-May-85 1810 GSB@MIT-MC hash table types -- ROT
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 20 May 85 18:10:18 PDT
Date: Mon, 20 May 85 21:11:13 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: hash table types -- ROT
To: common-lisp@SU-AI
Message-ID: <[MIT-MC].511876.850520.GSB>
NIL has a ROT function which rotates within a fixnum size. It was
there years and years ago, and never taken out. The ONLY use within
all of NIL is hidden inside a macro which combines hash codes, called
SXHASH-COMBINE -- (SXHASH-COMBINE n1 n2 ...) crunches together its
arguments, rotating them varying amounts first.
I can't say i've ever wanted to use ROT in any other circumstance. I
have on occasion, however, thought about a LDB which sign-extends.
∂20-May-85 1844 GSB@MIT-MC terminology
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 20 May 85 18:44:39 PDT
Date: Mon, 20 May 85 21:46:08 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: terminology
To: common-lisp@SU-AI
Message-ID: <[MIT-MC].511948.850520.GSB>
I haven't looked through the manual in a while so don't remember
exactly what terminology it uses for these things. But... Two of
the terms which I have been asked about many times (with reference to
CLtM, but also to the NIL manual and maybe also Lisp machine lisp
documentation) are "function" and "special form". Not even including
referential issues ("the name of"), "function" has been taken to mean
those things which you can apply, and sometimes those PLUS macros and
special forms. The definition of FUNCTIONP does not help things
either.
The use of "form" in special form leads to additional confusion -- is
"(if this that something-else)" a special-form, or is "if" a special
form? I would much prefer "special operator", although that leads me
to say that "operator" should be used to refer to {special-operators,
macros, functions}.
∂20-May-85 2252 REM@IMSSS FORM vs. FUNCTION etc.
Received: from IMSSS by SU-AI with PUP; 20-May-85 22:51 PDT
Date: 20 May 1985 2247-PDT
From: Rem@IMSSS
Subject: FORM vs. FUNCTION etc.
To: COMMON-LISP@SU-AI
It seems to me the following is consistent usage close to LISP tradition:
A 'form' is an executable s-expression, i.e. something that might reasonably
be passed to EVAL or pass through the compiler. Forms are atomic or
non-atomic. Non-atomic forms have two parts, the function part (the CAR,
which may be a function or the name of a function or something analagous)
and the argument part (the CDR, which is usually a list of arguments but
may be rather strange in macros and special-forms). Perhaps anything that
can fit in the function part of a form should be called a 'function',
but in CL that term has been restricted to omit macros and special-forms
[sic]. Alternatively it could be called an 'operator'. Thus an operator
would be either a function or a macro-operator or a special-operator
or the names of any of those: I.e. any of #<FUNCTION 2 174625> or
(LAMBDA (X) (PLUS 5 X)) or ADD5 or #<MACRO 126453> or PROG1 or
#<FEXPR 142231> or GO. (Don't take those code-pointers literally, DWIM.)
So, is it likely we can agree on some consistent usage that distinguishes
a function or operator (or its name) from a form containing it?
-------
∂21-May-85 0801 RWK@SCRC-STONY-BROOK.ARPA Backquote idioms
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 21 May 85 08:01:10 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 240608; Tue 21-May-85 11:00:56-EDT
Date: Tue, 21 May 85 11:00 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Backquote idioms
To: Guy Steele <gls%AQUINAS@THINK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850517125728.2.GLS@DESIDERIUS.ARPA>
Message-ID: <850521110036.5.RWK@CROW.SCRC.Symbolics.COM>
Date: Friday, 17 May 1985, 12:57-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Has anyone ever undertaken a study or catalog of backquote idioms?
Those of you who have used backquote at all seriously have probably come
to regard
', ,', ,, ,@, ,@', ,',',
---------------------------------------------------------↑↑↑↑
Shades of back-quote TECO! I discourage people from nesting
things three deep, and never do in my code! It makes the
list of idioms too long.
Anyway, to contribute my own "idiom" and thoughts to your list:
You *NEVER* see ,',@. It's useful to recognize this one as
an error. (It helps to look at it as ,(QUOTE ,@X), and to
remember that QUOTE does not take a variable number of arguments.)
When I'm explaining backquote to people, I stick with the
following list, as the "most useful" and "easiest explained".
, ', ,', ,@',
And, of course, the error case above, which helps them remember
it's ,@', not ,',@.
Personally, I feel we would do well to include a list of idioms
in the next CLtL and recommend that people stick with the set of
idioms. It makes it a lot easier to read code if you only have
to contend with a fixed set of "tokens".
I think a little taxonomy of idioms is useful:
In most usage of nested back-quoting, the form produced is going to be
evaluated once per level.
Doing (SETQ ARGS '('A 'AA 'AAA))
(setq f '``(list ,@(list ,@ARGS)))
(eval f) ==> `(LIST A AA AAA)
(eval (eval f)) ==> (LIST A AA AAA)
In this case, we see that A, AA, and AAA, while originally quoted, are
about to be evaluated in the resulting form. This double evaluation
is a charactaristic of all of these idioms which have more than one
more comma than quote. I.e. ,, ,@, ,,@ and ,@(list ,@ARGS)
In general, it is rarely the right thing for something to be evaluated
multiple times. We rarely write A and expect the value of A's value.
I find this division of these idioms into "single-evaluation",
"multiple evaluation" and "complete error" to be quite helpful. I
consider any use of "multiple evaluation" idioms to be suspect when
I'm looking for bugs in code. Also, since I can never construct convincing
examples of when they're useful when I'm showing someone backquote, I
usually don't explain them at all the first time around.
However, it seems to me that ,@(LIST is the same as just plain comma.
I.e. the following also gives the same result.
(setq f1 '``(list ,,@args))
(eval f1) ==> `(LIST A AA AAA)
(eval (eval f1)) ==> (LIST A AA AAA)
Is there really a reason to add ,@(LIST ,@ to our lexicon?
∂21-May-85 0848 JAR@MIT-MC "Special Operator"
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 May 85 08:48:43 PDT
Date: Tue, 21 May 85 11:49:46 EST
From: Jonathan A Rees <JAR@MIT-MC>
Subject: "Special Operator"
To: common-lisp@SU-AI
In-reply-to: Msg of Sat 18 May 85 14:11 EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Message-ID: <[MIT-MC].512627.850521.JAR>
Date: Sat, 18 May 85 14:11 EDT
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
... Also, I'd like to replace the term "special form" with "special
operator" when it doesn't apply to the whole form. ie, COND is not a
special form, it is a special operator.
Creating a new term to permit this distinction is an excellent idea.
Saying that COND is a special form is like saying that CAR is a function
call.
Jonathan
∂21-May-85 2211 Moon@SCRC-VALLECITO.ARPA terminology
Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 21 May 85 22:11:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 14543; Tue 21-May-85 21:21:59-EDT
Date: Tue, 21 May 85 21:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: terminology
To: Glenn S. Burke <GSB@MIT-MC.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[MIT-MC].511948.850520.GSB>
Message-ID: <850521212134.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 20 May 85 21:46:08 EST
From: Glenn S. Burke <GSB@MIT-MC>
The use of "form" in special form leads to additional confusion -- is
"(if this that something-else)" a special-form, or is "if" a special
form? I would much prefer "special operator", although that leads me
to say that "operator" should be used to refer to {special-operators,
macros, functions}.
I agree with this. I also believe (but haven't checked recently) that this
is the terminology used in Symbolics documentation and training (except that
not all of the documentation has yet been updated to conform to the standard
terminology).
∂22-May-85 0805 gls%AQUINAS@THINK.ARPA Backquote idioms
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 22 May 85 08:04:48 PDT
Received: by THINK.ARPA with CHAOS id AA16659; Wed, 22 May 85 10:55:58 edt
Date: Wednesday, 22 May 1985, 10:56-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Backquote idioms
To: ALAN@MIT-MC@THINK.ARPA, JAR@MIT-MC
Cc: common-lisp@sail, gls%AQUINAS@THINK.ARPA
In-Reply-To: <[MIT-MC].513387.850521.ALAN>
Message-Id: <850522105634.1.GLS@MUNGO.ARPA>
Received: from GODOT by AQUINAS via CHAOS with CHAOS-MAIL; Tue 21-May-85 22:44:45-EDT
Received: from MIT-MC (mit-mc.arpa.ARPA) by THINK.ARPA id AA13184; Tue, 21 May 85 22:34:23 edt
Date: Tue, 21 May 85 22:34:20 EST
From: Alan Bawden <ALAN@MIT-MC@think>
Subject: Backquote idioms
To: JAR@MIT-MC
Cc: GLS@MIT-MC
In-Reply-To: Msg of Tue 21 May 85 12:39:38 EST from Jonathan A Rees <JAR>
Message-Id: <[MIT-MC].513387.850521.ALAN>
Date: Tue, 21 May 85 12:39:38 EST
From: Jonathan A Rees <JAR>
Date: Monday, 20 May 1985, 10:48-EDT
From: Guy Steele <gls at AQUINAS>
Much to my surprise, I find that
(a) ,,@ *is* supported by Common Lisp.
(b) ,,@ is equivalent to ,@(list ,@
Alan told me that `(,b) was allowed to expand to (cons b nil) , which
would cause ,,@ to not work: ``(,,@x) ==> `(cons ,@x nil)
I don't have my CLTL handy, so I can't check this.
Steele is right! I have been making fun of the crazy grammar that the CL
book uses to explain backquote expansion, but no more! According to that
grammar all of ",,@", ",@,", ",@,@" and ",@'," work as expected! I didn't
bother to work out all of the three level comma combinations, I expect they
work too, but I can't figure out at the moment if ",@',,@" makes sense...
We could start sending bug reports to all of the backquote implementation
that fail to meet the CL specification. I would predict that that would
involve us in nit-picking discussions of the precise meaning of the list of
"ligitimate" expansions given at the top of page 351.
My position is that the examples on page 351 are all correct, but there
should also be examples illustrating that they are not all correct if
any of the items is a ,@-d form. I suspect that the problem in most
implementations that fail my funny example is that there is an
overzealous simplifier that is not checking for nested ,@ before
simplifying.
By the way, ',@x is not always an error! It does make sense if x is
exactly a singleton list. Sometimes this is useful in obscure cases.
Similarly, ,@',,@x makes sense if x is a singleton list. See the end of
this note.
I have constructed a version of backquote that rigorously follows the
backquote grammar on pages 349-350, and then optionally applies a
simplifier of my own random device. Here follow a bunch of examples.
For each example is shown:
the original backquoted form
the unsimplified expansion
the simplified expansion
result of applying EVAL once
result of applying EVAL twice
...
result of applying EVAL as many times as there were backquotes
;;; First, some useful data for the examples.
(defun foo (x) (list 'fooed x))
(setq q '(r s))
(defun r (x) (reduce #'* x))
(setq r '(3 5))
(setq s '(4 6))
``(,,q)
(APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) (LIST Q))))
(LIST 'LIST Q)
(LIST (R S))
(24)
``(,@,q)
(APPEND (LIST 'APPEND) (LIST Q))
Q
(R S)
24
``(,,@q)
(APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) Q)))
(CONS 'LIST Q)
(LIST R S)
((3 5) (4 6))
``(,@,@q)
(APPEND (LIST 'APPEND) Q)
(CONS 'APPEND Q)
(APPEND R S)
(3 5 4 6)
`(foo `(bar ,,q))
(APPEND (LIST 'FOO)
(LIST (APPEND (LIST 'APPEND)
(LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR)))))
(LIST (APPEND (LIST 'LIST) (LIST Q))))))
(LIST 'FOO (LIST 'LIST '(QUOTE BAR) Q))
(FOO (LIST (QUOTE BAR) (R S)))
(FOOED (BAR 24))
`(foo `(bar ,@,q))
(APPEND (LIST 'FOO)
(LIST (APPEND (LIST 'APPEND)
(LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR)))))
(LIST Q))))
(LIST 'FOO (LIST 'CONS '(QUOTE BAR) Q))
(FOO (CONS (QUOTE BAR) (R S)))
(FOOED (BAR . 24))
`(foo `(bar ,,@q))
(APPEND (LIST 'FOO)
(LIST (APPEND (LIST 'APPEND)
(LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR)))))
(LIST (APPEND (LIST 'LIST) Q)))))
(LIST 'FOO (LIST* 'LIST '(QUOTE BAR) Q))
(FOO (LIST (QUOTE BAR) R S))
(FOOED (BAR (3 5) (4 6)))
`(foo `(bar ,@,@q))
(APPEND (LIST 'FOO)
(LIST (APPEND (LIST 'APPEND)
(LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR)))))
Q)))
(LIST 'FOO (LIST 'CONS '(QUOTE BAR) (CONS 'APPEND Q)))
(FOO (CONS (QUOTE BAR) (APPEND R S)))
(FOOED (BAR 3 5 4 6))
``(,',q)
(APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST Q))))))
(LIST 'QUOTE (LIST Q))
(QUOTE ((R S)))
((R S))
``(,@',q)
(APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'QUOTE) (LIST Q))))
(LIST 'QUOTE Q)
(QUOTE (R S))
(R S)
`(foo `(bar ,',q))
(APPEND (LIST 'FOO)
(LIST (APPEND (LIST 'APPEND)
(LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR)))))
(LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST Q))))))))
(LIST 'FOO (LIST 'QUOTE (LIST 'BAR Q)))
(FOO (QUOTE (BAR (R S))))
(FOOED (BAR (R S)))
`(foo `(bar ,@',q))
(APPEND (LIST 'FOO)
(LIST (APPEND (LIST 'APPEND)
(LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR)))))
(LIST (APPEND (LIST 'QUOTE) (LIST Q))))))
(LIST 'FOO (LIST 'QUOTE (CONS 'BAR Q)))
(FOO (QUOTE (BAR R S)))
(FOOED (BAR R S))
`(foo `(bar ',',q))
(APPEND
(LIST 'FOO)
(LIST (APPEND (LIST 'APPEND)
(LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR)))))
(LIST (APPEND (LIST 'LIST)
(LIST (APPEND (LIST 'APPEND)
(LIST (APPEND (LIST 'LIST)
(LIST (APPEND (LIST 'QUOTE)
(LIST 'QUOTE)))))
(LIST (APPEND (LIST 'LIST)
(LIST (APPEND (LIST 'QUOTE)
(LIST Q))))))))))))
(LIST 'FOO (LIST 'QUOTE (LIST 'BAR (LIST 'QUOTE Q))))
(FOO (QUOTE (BAR (QUOTE (R S)))))
(FOOED (BAR (QUOTE (R S))))
```(,@',,@q) ;Alan's example
(APPEND (LIST 'APPEND)
(LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'APPEND)))))
(LIST (APPEND (LIST 'LIST)
(LIST (APPEND (LIST 'APPEND)
(LIST (APPEND (LIST 'LIST)
(LIST (APPEND (LIST 'QUOTE)
(LIST 'QUOTE)))))
(LIST (APPEND (LIST 'LIST) Q)))))))
(LIST* 'LIST '(QUOTE QUOTE) Q)
(LIST (QUOTE QUOTE) R S)
(QUOTE (3 5) (4 6))
<error> ;but would be sensible if Q were the singleton list (R),
; in which case third evaluation would produce (3 5).
Do you all believe these?
--Guy
∂22-May-85 0853 DCP@SCRC-STONY-BROOK.ARPA Backquote idioms
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85 08:53:29 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 241751; Wed 22-May-85 11:52:45-EDT
Date: Wed, 22 May 85 11:54 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Backquote idioms
To: Guy Steele <gls%AQUINAS@THINK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850522105634.1.GLS@MUNGO.ARPA>
Message-ID: <850522115407.9.NFEP@NEPONSET.SCRC.Symbolics.COM>
Date: Wednesday, 22 May 1985, 10:56-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
```(,@',,@q) ;Alan's example
...etc...
(QUOTE (3 5) (4 6))
<error> ;but would be sensible if Q were the singleton list (R),
; in which case third evaluation would produce (3 5).
Do you all believe these?
Does it matter? RWK said he has never used a triple backquote. Neither
have I. There may be applications which are really good hacks, but can
they be maintained? Even some double nested backquotes require enough
though that they should probably be avoided. Conciseness and
compactness does not imply clarity and robustness.
∂22-May-85 0906 BSG@SCRC-RIVERSIDE.ARPA Backquote idioms
Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 22 May 85 09:06:07 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-RIVERSIDE.ARPA via CHAOS with CHAOS-MAIL id 38658; Wed 22-May-85 12:05:20-EDT
Date: Wed, 22 May 85 12:04 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Backquote idioms
To: DCP@SCRC-QUABBIN.ARPA, gls%AQUINAS@THINK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850522115407.9.NFEP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <850522120451.4.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Wed, 22 May 85 11:54 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Date: Wednesday, 22 May 1985, 10:56-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
```(,@',,@q) ;Alan's example
...etc...
(QUOTE (3 5) (4 6))
<error> ;but would be sensible if Q were the singleton list (R),
; in which case third evaluation would produce (3 5).
Do you all believe these?
Does it matter? RWK said he has never used a triple backquote. Neither
have I. There may be applications which are really good hacks, but can
they be maintained? Even some double nested backquotes require enough
though that they should probably be avoided. Conciseness and
compactness does not imply clarity and robustness.
From LMFS:DEFSTORAGE (part of PL/I record simulating substrate of File System):
(defmacro once-onlify-index-offset (form)
(let ((do-it-p (gensym))
(was-ixo (gensym))
(ggs (gensym)))
`(let ((,do-it-p (not (atom *defstorage-index-offset*)))
(,was-ixo *defstorage-index-offset*))
(let-if ,do-it-p ;Guaranteed needs wrapping now.
((*defstorage-index-offset* '',ggs))
(wrap-if (symbolp ,was-ixo) ;Needs once-onlying at macro time.
`(once-only (,,was-ixo) ,:the-form)
(wrap-if ,do-it-p
``(let ((,',',ggs ,,,was-ixo)) ,,:the-form)
,form))))))
Admittedly, now that there are "language tools", this can be done better.
Also, idioms like
`',
and the like should be discussed. I have always been amused by
the analogy to tensor subscripts and superscripts and their
contraction rules.
∂22-May-85 1010 DCP@SCRC-STONY-BROOK.ARPA Backquote idioms
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85 10:09:41 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 241800; Wed 22-May-85 12:48:22-EDT
Date: Wed, 22 May 85 12:49 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Backquote idioms
To: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>,
DCP@SCRC-QUABBIN.ARPA, gls%AQUINAS@THINK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850522120451.4.BSG@CONCORD.SCRC.Symbolics.COM>
Message-ID: <850522124944.2.NFEP@NEPONSET.SCRC.Symbolics.COM>
Date: Wed, 22 May 85 12:04 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Date: Wed, 22 May 85 11:54 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Date: Wednesday, 22 May 1985, 10:56-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
```(,@',,@q) ;Alan's example
...etc...
(QUOTE (3 5) (4 6))
<error> ;but would be sensible if Q were the singleton list (R),
; in which case third evaluation would produce (3 5).
Do you all believe these?
Does it matter? RWK said he has never used a triple backquote. Neither
have I. There may be applications which are really good hacks, but can
they be maintained? Even some double nested backquotes require enough
though that they should probably be avoided. Conciseness and
compactness does not imply clarity and robustness.
From LMFS:DEFSTORAGE (part of PL/I record simulating substrate of File System):
(defmacro once-onlify-index-offset (form)
(let ((do-it-p (gensym))
(was-ixo (gensym))
(ggs (gensym)))
`(let ((,do-it-p (not (atom *defstorage-index-offset*)))
(,was-ixo *defstorage-index-offset*))
(let-if ,do-it-p ;Guaranteed needs wrapping now.
((*defstorage-index-offset* '',ggs))
(wrap-if (symbolp ,was-ixo) ;Needs once-onlying at macro time.
`(once-only (,,was-ixo) ,:the-form)
(wrap-if ,do-it-p
``(let ((,',',ggs ,,,was-ixo)) ,,:the-form)
,form))))))
Admittedly, now that there are "language tools", this can be done better.
I would not want to maintain this, especially the line
``(let ((,',',ggs ,,,was-ixo)) ,,:the-form)
Is that ,,, really correct, or are you using the fact that NIL and T are
self evaluating? If you have to think about that for more than 10
seconds, something is wrong. If it is obvious to you, I commend you for
your understanding of complex uses of backquote, and ask you to take
pity on the rest of us.
I'll contend it can be done better without language tools. For example,
you could build the form from the inside out, instead of your outside in
method. Something like (I'm not sure what the semantics of :the-form
are, so I'll guess),
(defmacro once-onlify-index-offset (form)
(let ((do-it-p (gensym))
(was-ixo (gensym))
(ggs (gensym)))
`(let ((,do-it-p (not (atom *defstorage-index-offset*)))
(,was-ixo *defstorage-index-offset*))
(let-if ,do-it-p ((*defstorage-index-offset* '',ggs))
(setq form (wrap-if ,do-it-p
`(let ((,',ggs ,,was-ixo)) ,:the-form)
form))
(setq form (wrap-if (symbolp ,was-ixo)
`(once-only (,,was-ixo) ,:the-form)
form))
form))))
I also have personal problems with macros that do computation instead of
translation.
Also, idioms like
`',
and the like should be discussed. I have always been amused by
the analogy to tensor subscripts and superscripts and their
contraction rules.
∂22-May-85 1012 DDYER@USC-ISIB.ARPA Local SPECIAL declarations
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 22 May 85 10:10:59 PDT
Date: 22 May 1985 10:05:16 PDT
Subject: Local SPECIAL declarations
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: common-lisp@SU-AI.ARPA
I want to put in a good word for the use of local rather than
global "SPECIAL" declarations. Local Specials are the perfect
way to implement communication among functions that aren't
lexically related, and where the information being passed
in the specials is only needed among a few functions. The
discipline of including the SPECIAL declaractions in every
function focuses attention on the fact that this particular
variable is indeed "special" in the ordinary sense as well
as lisp's sense of the word.
-------
∂22-May-85 1142 smh@mit-eddie.ARPA Re: Backquote idioms
Received: from MIT-EDDIE.ARPA by SU-AI.ARPA with TCP; 22 May 85 11:41:56 PDT
Received: by mit-eddie.ARPA (4.12/4.8) id AA16866; Wed, 22 May 85 14:33:01 edt
Date: Wed, 22 May 85 14:33:01 edt
From: Steven M. Haflich <smh@mit-eddie.ARPA>
Message-Id: <8505221833.AA16866@mit-eddie.ARPA>
To: common-lisp@su-ai.ARPA
Subject: Re: Backquote idioms
From @SU-AI.ARPA:DCP@SCRC-STONY-BROOK.ARPA Wed May 22 12:01:25 1985
Subject: Backquote idioms
Do you all believe these?
Does it matter? RWK said he has never used a triple backquote.
Neither have I. There may be applications which are really good
hacks, but can they be maintained? Even some double nested backquotes
require enough though[t] that they should probably be avoided.
Conciseness and compactness does not imply clarity and robustness.
I plead that it *does* matter. It does not depend on the wisdom of
anyone (other than my good friend Bernie) writing triple nested
backquotes. Consider rather automatic code generators. Sometimes a
code generator needs output source code to a file, instead of
generating forms in memory. Backquotes exist not to provide any
additional expressiveness in printed representations, but (roughly) to
make clearer constructions which embed the results of form evaluation
inside a template. It is conceivable that a good automatic code
generator could use backquotes to aid human readablility of its
output, if only to aid debugging. But an automatic code generator
might, like Bernie, lack sufficient discretion not to nest backquotes
in cases where readability is indeed *not* enhanced.
I apologise to BSG for pulling his leg a little, but the point is
serious: CLTL must either document firmly that more than two levels
of backquotes are undefined, or else the reader grammar must be clear
and obeyed by all implementations.
∂22-May-85 1155 gls@AQUINAS.ARPA Backquote idioms
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 22 May 85 11:55:02 PDT
Received: by THINK.ARPA with CHAOS id AA20244; Wed, 22 May 85 14:49:16 edt
Date: Wed, 22 May 85 14:49 EDT
From: Guy Steele <gls@AQUINAS.ARPA>
Subject: Backquote idioms
To: BSG@SCRC-STONY-BROOK.ARPA, DCP@SCRC-QUABBIN.ARPA, gls%AQUINAS@GODOT.ARPA
Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.ARPA
In-Reply-To: <850522124944.2.NFEP@NEPONSET.SCRC.Symbolics.COM>
Message-Id: <850522144942.2.GLS@UBALDO.ARPA>
While I am not prepared to defend the clarity of the original
ONCE-ONLIFY-INDEX-OFFSET, I can say that the proposed replacement
bothers me because of the repeated SETQ-ing of the argument variable
FORM. It's hard to condemn nesting per se, as LISP is perhaps the
quintessence of nesting languages.
I think it *is* quite clear, with an order of magnitude less than ten
seconds' thought, that ONCE-ONLIFY-INDEX-OFFSET is not depending on
repeated evaluation of T or NIL: the value of WAS-IXO is a gensym, which
is certainly not T or NIL. (In fact, that gensym is bound by a LET
generated by the first level of backquote.)
I have, once or twice in my career, had a need to write a macro that
generates macros that generate code--and then need to abstract that
ouetr macro yet again. This leads to triply nested backquotes.
Generating things incrementally this way is not difficult at all,
proceeding one layer of abstraction at a time. I wanted to investigate
things from the point of the (human) reader, who sees the whole thing
all at once.
I use `',x a LOT.
--Guy
∂22-May-85 1206 Masinter.pa@Xerox.ARPA Backquote idioms
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 22 May 85 12:06:09 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 MAY 85 12:05:25 PDT
Date: 22 May 85 12:05 PDT
From: Masinter.pa@Xerox.ARPA
Subject: Backquote idioms
To: common-lisp@su-ai.ARPA
Many of these issues would be moot if the implementation of backquote
were specified in terms of what the read-macro generated, and the
implementation of the macros that it then expanded to. Implementations
could diverge from the "specified" one only if their divergence was
invisible.
It might mean that some of the current implementations might have to
change, but if the "specified" implementation is faithful in
implementing the book, it couldn't mean too much disruption in existing
code, could it?
∂22-May-85 1213 KMP@SCRC-STONY-BROOK.ARPA Re: Backquote idioms
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85 12:12:48 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 241931; Wed 22-May-85 15:12:23-EDT
Date: Wed, 22 May 85 15:12 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Re: Backquote idioms
To: smh@MIT-EDDIE.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8505221833.AA16866@mit-eddie.ARPA>
Message-ID: <850522151235.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Wed, 22 May 85 14:33:01 edt
From: Steven M. Haflich <smh@mit-eddie.ARPA>
From @SU-AI.ARPA:DCP@SCRC-STONY-BROOK.ARPA Wed May 22 12:01:25 1985
Subject: Backquote idioms
Do you all believe these?
Does it matter? RWK said he has never used a triple backquote.
Neither have I. There may be applications which are really good
hacks, but can they be maintained? Even some double nested backquotes
require enough though[t] that they should probably be avoided.
Conciseness and compactness does not imply clarity and robustness.
I plead that it *does* matter. It does not depend on the wisdom of
anyone (other than my good friend Bernie) writing triple nested
backquotes. Consider rather automatic code generators. Sometimes a
code generator needs output source code to a file, instead of
generating forms in memory. Backquotes exist not to provide any
additional expressiveness in printed representations, but (roughly) to
make clearer constructions which embed the results of form evaluation
inside a template. It is conceivable that a good automatic code
generator could use backquotes to aid human readablility of its
output, if only to aid debugging. But an automatic code generator
might, like Bernie, lack sufficient discretion not to nest backquotes
in cases where readability is indeed *not* enhanced.
Indeed. All too much mail on this list recently seems to address the
issue of what `reasonable people' should do. As much as possible,
people shouldn't be writing programs; programs should be writing programs.
And as such, it matters critically that language features be clearly
defined to arbitrary levels of complexity. eg, I have programs that
convert backquote syntax to LIST syntax and back, and I would be -very-
aggravated if I had to pass level-number parameters around to make sure
I wasn't nesting excessively. Just because people get bogged down with
the number 7 plus or minus 2 doesn't mean programs do...
I also disagree fully with the notion that 3-level is too deep. I think
,',',',',', is quite readable. I don't think ,',,',',, is as readable.
Probably most of us find CAAAAAAAAR more readable than CADAADDAAR, though.
I do use triply-nested backquote, though, and believe it to be even
stylistically reasonable on occassion.
I apologise to BSG for pulling his leg a little, but the point is
serious: CLTL must either document firmly that more than two levels
of backquotes are undefined, or else the reader grammar must be clear
and obeyed by all implementations.
Fine for a style handbook to claim that common idioms are preferred,etc
but not fine for the language spec to take any stand at all other than
to say what the definition is in a way that is neatly recursively defined.
∂22-May-85 1343 DCP@SCRC-STONY-BROOK.ARPA Re: Backquote idioms
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85 13:41:09 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242016; Wed 22-May-85 16:40:27-EDT
Date: Wed, 22 May 85 16:41 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Re: Backquote idioms
To: Steven M. Haflich <smh@MIT-EDDIE.ARPA>,
Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8505221833.AA16866@mit-eddie.ARPA>,
<850522151235.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <850522164152.8.NFEP@NEPONSET.SCRC.Symbolics.COM>
I am not saying that 69 levels of backquote should not be defined. I am
saying that it should not be encouraged for people writing programs.
(After all, how do program writing programs bootstrap?) I have no
objections to programs outputing 69 levels of backquoted structure, as
long as a human never has to go near it; only some (possibly other)
program should need to reinterpret it.
As for what CLtL should say, I think it should say that backquote works
to indefinite levels of nesting. I think it should give the common
idioms. I think it should say that the deeper the nesting, the greater
the loss of clarity to the human reader and the <some number> (2 for me
and probably most people in this day and age) is what is considered
within the normal style of programming. [I refer the audience to "The
Program Feature" where it uses the word 'style' many times.]
Note: I finally found where backquote is documented. it would be nice
if there were a 'backquote' entry in the index.
∂22-May-85 1600 RWK@SCRC-STONY-BROOK.ARPA Backquote idioms
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85 16:00:10 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242126; Wed 22-May-85 18:59:40-EDT
Date: Wed, 22 May 85 18:59 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Backquote idioms
To: Guy Steele <gls%AQUINAS@THINK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850522105634.1.GLS@MUNGO.ARPA>
Message-ID: <850522185932.7.RWK@CROW.SCRC.Symbolics.COM>
Date: Wednesday, 22 May 1985, 10:56-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
By the way, ',@x is not always an error! It does make sense if x is
exactly a singleton list. Sometimes this is useful in obscure cases.
Similarly, ,@',,@x makes sense if x is a singleton list. See the end of
this note.
I think "is an error" is still the right phrase to apply.
Just because there happens to be a value that does not result
in an error does not make it proper. I think it is *MUCH*
clearer to write ',(CAR X). You can do additional error
checking on X if you like, and signal a comprehensible
error, rather than depending on QUOTE to check! (I have
seen implementations where QUOTE did not check).
∂22-May-85 1927 Moon@SCRC-STONY-BROOK.ARPA Special form terminology
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85 19:27:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242291; Wed 22-May-85 22:19:24-EDT
Date: Wed, 22 May 85 22:19 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Special form terminology
To: Common-Lisp@SU-AI.ARPA
References: <850522182532.3.ACW@ROCKY-MOUNTAINS.SCRC.Symbolics.COM>
Message-ID: <850522221918.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
The following message may be of interest to you:
Date: Wed, 22 May 85 18:25 EDT
From: Allan C. Wechsler <acw@WAIKATO.SCRC.Symbolics.COM>
The line we have taken at Ed. Services is that macros are a subclass of
special operator. The taxonomic tree we have been using looks like
this:
Operators
←←←←←←←←←←/\←←←←←
| |
Functions Special Operators
←←←←←←←←←←←←/\←←←←←←←←←←←←
| |
Macros Primitive Special Operators (PSOs)
This way we have a name for each useful subdivision. Also, we need not
distinguish macros from PSOs when it suits us not to. I think that
whether a special operator is a PSO or a macro is often an
implementation detail, which we shouldn't have to document in case we
change our minds.
So when I teach DEFSTRUCT, for example, I say it's a special operator.
The students don't care whether it's primitive or not. They do care
that it does not have function semantics.
∂22-May-85 1927 DLW@SCRC-STONY-BROOK.ARPA Macros -> declarations
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85 19:27:18 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242258; Wed 22-May-85 21:20:26-EDT
Date: Wed, 22 May 85 21:20 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Macros -> declarations
To: Fahlman@CMU-CS-C.ARPA, Masinter.pa@XEROX.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12111607133.BABYL@CMU-CS-C.ARPA>
Message-ID: <850522212037.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Reply-To: dlw@SCRC-STONY-BROOK.ARPA
Date: Thu, 16 May 1985 22:45 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
But
we should only make this move so late in the game if just about everyone
else feels likewise.
-- Scott
Taking this a few steps further, I think it's important that we decide
what our philosophy is about "changes to Common Lisp", particularly in
light of the fact that the manual has been published and is now on the
shelves of bookstores. What does it mean for us to "make a move"?
This is not intended as a criticism of Masinter's suggestion or any
other particular suggestion (I actually like the suggestion, although I
haven't considered it carefully). I just think we'd spend our time
better if it were somewhat more clear what game we are playing and what
the rules are, and I'm worried that we're spending a great deal of time
and energy designing Common Lisp after the horse has been let out of the
barn. Are we really designing a new second-generation Common Lisp? Or
are we proposing to tell the world shortly that the book isn't really
the Real Common Lisp, please make the following forty changes to your
copy? Once we have answered this question, then we can agree on a general
philosophy about what degree of change is allowable.
∂22-May-85 2057 RAM@CMU-CS-C.ARPA Adjustable and displaced arrays
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 22 May 85 20:56:58 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 22 May 85 23:56:52-EDT
Date: Wed, 22 May 1985 23:56 EDT
Message-ID: <RAM.12113193061.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Adjustable and displaced arrays
I am somewhat confused about the interaction between array adjustment
and displacement.
In CLTL p298:
Note that if the array a is created displaced to array b and
subsequently array b is given to adjust-array, array a will still
be displaced to array b; the effects of this displacement and the
rule of row-major storage order must be taken into account.
What is this trying to say? Is this a warning to the user or a threat
to the implementor? The obvious interpretation of this statement
seems to require that all non-simple arrays contain a list of all the
other array headers that share the same data so that they can be fixed
up when the array is adjusted. The answer that you stick in a
forwarding pointer is not acceptable.
The statement in the manual also doesn't answer the question of what
happens to array b if array a is adjusted. Is it legal or meaningful
to have arrays which are both displaced to another array and
adjustable? What are the semantics of adjusting such an array?
Rob
∂22-May-85 2108 DLW@SCRC-STONY-BROOK.ARPA EQUALP hash tables (and more ...)
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85 21:08:22 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242358; Thu 23-May-85 00:07:47-EDT
Date: Thu, 23 May 85 00:08 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: EQUALP hash tables (and more ...)
To: Fahlman@CMU-CS-C.ARPA, hoey@NRL-AIC.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12110566837.BABYL@CMU-CS-C.ARPA>
Message-ID: <850523000805.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Reply-To: dlw@SCRC-STONY-BROOK.ARPA
Date: Sun, 12 May 1985 23:30 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
So I guess the point is that given magic EQ and EQL hashtables that work
even when a GC moves things, you can use these to build a slower version
of EQ and EQL hashtables (and related thingies) that also works, without
giving the users direct access to the magic. Interesting in principle,
but not the way you'd want to do anything real.
Au contraire. Multics Maclisp uses this to implement the wonderful
Maclisp MAKNUM and MUNKAM functions. I suppose it depends on what
you mean by "real"...
∂23-May-85 0130 STEINER@RUTGERS.ARPA Does FORMAT handle multiple values
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 23 May 85 01:30:41 PDT
Date: 23 May 85 04:30:24 EDT
From: Dave <Steiner@RUTGERS.ARPA>
Subject: Does FORMAT handle multiple values
To: Common-Lisp@SU-AI.ARPA
Does format handle multiple values at all? What I want to do is
something like the following (only this throws away everything but
the first value):
(format t "~S~%" (progn ... (values ...)))
Is there anyway to handle this (or should it be handling it but there
is a bug in our CLisp)?
BTW, I'm sure that I can do this with a values-list and the iteration
directive but I wanted to know if I can do this without knowing a
head of time whether I would be getting mv's back or not.
thanks,
ds
uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner
arpa: Steiner@RUTGERS
-------
∂23-May-85 0157 RAM@CMU-CS-C.ARPA Does FORMAT handle multiple values
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 23 May 85 01:57:27 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 23 May 85 04:57:06-EDT
Date: Thu, 23 May 1985 04:57 EDT
Message-ID: <RAM.12113247712.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Dave <Steiner@RUTGERS.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Does FORMAT handle multiple values
In-reply-to: Msg of 23 May 1985 04:30-EDT from Dave <Steiner at RUTGERS.ARPA>
Date: Thursday, 23 May 1985 04:30-EDT
From: Dave <Steiner at RUTGERS.ARPA>
To: Common-Lisp at SU-AI.ARPA
Re: Does FORMAT handle multiple values
(format t "~S~%" (progn ... (values ...)))
I'm not sure what you think that code is supposed to do, but there are
two ways that I can think of to turn MV's into format arguments (or
any other kind of arguments). You can use Multiple-Value-List (not
values-list, as you said) to get a list, or you can use
Multiple-Value-Call.
In Common Lisp, there is no user-visible distinction between returning
one value and returning one "multiple value", so the
multiple-value-### primitives will work fine even if only one value is
being returned.
Rob
∂23-May-85 0503 RAM@CMU-CS-C.ARPA Get-Setf-Method
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 23 May 85 05:03:34 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 23 May 85 08:03:33-EDT
Date: Thu, 23 May 1985 08:03 EDT
Message-ID: <RAM.12113281659.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Get-Setf-Method
Get-Setf-Method should take an (optional?) environment argument so
that it can expand macros correctly.
Rob
∂23-May-85 0657 greek@DEC-HUDSON Adjusting Displaced Arrays
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 23 May 85 06:57:36 PDT
Date: Thu, 23 May 85 09:57:23 EDT
From: greek@DEC-HUDSON
Subject: Adjusting Displaced Arrays
To: common-lisp@su-ai
We were so confused about the problem of adjusting displaced arrays,
we simply don't allow it in VAX LISP. I'd sure appreciate some
thoughts on the matter myself.
- Paul
∂23-May-85 0747 gls%AQUINAS@THINK.ARPA Does FORMAT handle multiple values
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 23 May 85 07:47:31 PDT
Received: by THINK.ARPA with CHAOS id AA04605; Thu, 23 May 85 10:42:58 edt
Date: Thursday, 23 May 1985, 10:43-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Does FORMAT handle multiple values
To: Common-Lisp%SU-AI.ARPA@THINK.ARPA
Cc: gls%AQUINAS@THINK.ARPA
In-Reply-To: Your message of 23 May 85 04:30-EDT
Message-Id: <850523104328.2.GLS@YON.ARPA>
Date: 23 May 85 04:30:24 EDT
From: Dave <Steiner@RUTGERS.ARPA@think>
Does format handle multiple values at all? What I want to do is
something like the following (only this throws away everything but
the first value):
(format t "~S~%" (progn ... (values ...)))
I would write this as
(multiple-value-call #'format t "~S~%" (progn ... (values ...)))
thereby causing multiple values from each argument form to be
"spread out" as separate arguments to FORMAT.
--Guy
∂23-May-85 0757 gls%AQUINAS@THINK.ARPA Adjustable and displaced arrays
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 23 May 85 07:57:41 PDT
Received: by THINK.ARPA with CHAOS id AA04649; Thu, 23 May 85 10:51:00 edt
Date: Thursday, 23 May 1985, 10:51-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Adjustable and displaced arrays
To: common-lisp%SU-AI@THINK.ARPA
Cc: gls%AQUINAS@THINK.ARPA
In-Reply-To: <RAM.12113193061.BABYL@CMU-CS-C.ARPA>
Message-Id: <850523105129.3.GLS@YON.ARPA>
Date: Wed, 22 May 1985 23:56 EDT
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA@think>
I am somewhat confused about the interaction between array adjustment
and displacement.
In CLTL p298:
Note that if the array a is created displaced to array b and
subsequently array b is given to adjust-array, array a will still
be displaced to array b; the effects of this displacement and the
rule of row-major storage order must be taken into account.
What is this trying to say? Is this a warning to the user or a threat
to the implementor? The obvious interpretation of this statement
seems to require that all non-simple arrays contain a list of all the
other array headers that share the same data so that they can be fixed
up when the array is adjusted. The answer that you stick in a
forwarding pointer is not acceptable.
This should be elucidated in the next edition. If you put this paragraph
beside the descriptions of :DISPLACED-TO and :DISPLACED-INDEX-OFFSET on pages
288-289, and assume that array a is essentially unaffected, one concludes
that array a is still displaced to array b, the mapping between elements
still being determined by taking the elements in row-major order and then
mapping element k of array a to element k+n of array b, where n is the
:displaced-index-offset for array a. The only difference is that array b,
having been adjusted, may have a different row-major ordering. (A nasty
problem is that the roles of arrays A and B are reversed on pages 288 and
298! Sorry about that.)
The statement in the manual also doesn't answer the question of what
happens to array b if array a is adjusted. Is it legal or meaningful
to have arrays which are both displaced to another array and
adjustable? What are the semantics of adjusting such an array?
Well, page 298 says that if A is displaced to X, then after adjustment of A,
A has no relationship to X, nor does the returned result, unless X is
respecified explicitly in the :displaced-to option to ADJUST-ARRAY.
I admit that this fails to state explicitly that X is unaffected.
Rob
∂23-May-85 0818 gls%AQUINAS@THINK.ARPA Rules of the game
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 23 May 85 08:17:49 PDT
Received: by THINK.ARPA with CHAOS id AA04768; Thu, 23 May 85 11:09:39 edt
Date: Thursday, 23 May 1985, 11:10-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Rules of the game
To: common-lisp%SU-AI@THINK.ARPA
Cc: gls%AQUINAS@THINK.ARPA
In-Reply-To: <850522212037.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <850523111007.4.GLS@YON.ARPA>
Date: Wed, 22 May 85 21:20 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM@think>
... I think it's important that we decide
what our philosophy is about "changes to Common Lisp", particularly in
light of the fact that the manual has been published and is now on the
shelves of bookstores. What does it mean for us to "make a move"?
... I just think we'd spend our time
better if it were somewhat more clear what game we are playing and what
the rules are, and I'm worried that we're spending a great deal of time
and energy designing Common Lisp after the horse has been let out of the
barn. Are we really designing a new second-generation Common Lisp? Or
are we proposing to tell the world shortly that the book isn't really
the Real Common Lisp, please make the following forty changes to your
copy? Once we have answered this question, then we can agree on a general
philosophy about what degree of change is allowable.
My attitude is that the horse is indeed out of the barn. I believe that changes
of the following five kinds are appropriate. I list them in order of increasing
seriousness and likeliness to cause disruption:
(1) Typographical and editorial corrections (such as a better index!). In
this category I would place changes in terminology that would leave code
unaffected. For example, changing the term "special form" to "special
operator" would fall into this category, but renaming SPECIAL-FORM-P to
SPECIAL-OPERATOR-P would not.
(2) Substantive elucidations of intent. An example of this is my reply earlier
today elucidating what is supposed to happen when adjusting an array to which
another array is displaced.
(3) Compatible extensions to the language (such as adding a quaternion data type,
or flavors, or Bessel functions, or PARSE-BODY, or the proposed three-variable
&BODY feature for DEFMACRO).
(4) Incompatible changes to existing features because they cannot possibly
operate correctly as specified. An example is the recent report that
GET-SETF-METHOD needs to take an environment argument.
(5) Incompatible changes required to bring Common Lisp into conformance with
an external standard. This category is fraught with danger, and the benefits
must be weighed carefully. An example is the proposal to change the branch
cuts of arctangent to conform to expected practice by the APL and IEEE
proposed floating-point communities.
I believe that it is too late for incompatible changes for the sake of
clarity, consistency, or convenience. Therefore I would strongly oppose
renaming or removing any existing function or feature. (This represents a
reversal of my previous position on the proposal to eliminate expansion of
macros into declarations.)
--Guy
∂23-May-85 0841 fateman%ucbdali@Berkeley rules of the game
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 23 May 85 08:40:52 PDT
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.46)
id AA09771; Thu, 23 May 85 08:38:42 pdt
Received: by ucbdali.ARPA (4.24/4.46)
id AA12133; Thu, 23 May 85 08:40:55 pdt
Date: Thu, 23 May 85 08:40:55 pdt
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8505231540.AA12133@ucbdali.ARPA>
To: common-lisp@su-ai
Subject: rules of the game
It seems to me that this was brought up at the Monterey meeting (by me).
That CLTL was an informal description of an approach to a Lisp dialect,
leaving a considerable amount of discretion to the implementor. A language
consistent with CLTL could be called compatible with CL'84 (say). When/if
there is another CL, one which has an official standard-setting description,
it could be called (say) CL '86. There could also be some subset CL standard.
The relationship between CL'84 and CL '86 could resemble the relationships
between the various Fortrans. Namely, they have similar names and intentions,
but are not necessarily compatible in detail.
To imply that CL is static will encourage people to design and promulgate
the YADOCL family of languages (Yet Another Derivative of Common Lisp).
Now if CL'84 stands in the same relation to Lisps of the next 20 years as
Lisp 1.5 stood to Lisps of the previous 20 years, this may also be OK.
It doesn't solve DARPA's problems of complete compatibility and portability
of code, but neither, after all, did CL '84.
I think it would be a mistake to be stubborn about changes.
P.S. the location of the branch cut for the complex atan is not likely to
affect any existing CL code, and I think that the IEEE or APL standards
committee might be followed without injury.
∂23-May-85 0939 GRISS%hp-hulk.csnet@csnet-relay.arpa Re: Local SPECIAL declarations
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 23 May 85 09:39:07 PDT
Received: from hplabs by csnet-relay.csnet id ad04548; 23 May 85 12:28 EDT
Received: by HP-VENUS id AA02099; Thu, 23 May 85 05:49:47 pdt
Message-Id: <8505231249.AA02099@HP-VENUS>
Date: Thu 23 May 85 05:49:20-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Re: Local SPECIAL declarations
To: DDYER, common-lisp@su-ai.ARPA
Cc: GRISS@hplabs.CSNET
In-Reply-To: Message from "Dave Dyer <DDYER@USC-ISIB@HP-VENUS>" of Wed 22 May 85 10:05:16-PDT
Source-Info: From (or Sender) name not authenticated.
I too like the notion of the local special. I once used a language
(BALM) that exploited $ at the point of binding as a readmacro;
(defun foo (x $y z)
(setq y 3))
which effectively expanded into
(defun foo (x (special y) z)
(setq y 3))
Perhaps the $ should have been used on ALL references to the special
y for more consistency.
It was very comfortable to use.
M
-------
∂23-May-85 1038 RAM@CMU-CS-C.ARPA Adjustable and displaced arrays
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 23 May 85 10:38:37 PDT
Received: from CMU-CS-C.ARPA (cmu-cs-c.arpa.ARPA) by THINK.ARPA id AA06595; Thu, 23 May 85 13:34:54 edt
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 23 May 85 13:35:06-EDT
Date: Thu, 23 May 1985 13:35 EDT
Message-Id: <RAM.12113342010.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Guy Steele <gls%AQUINAS@THINK.ARPA>
Cc: common-lisp%SU-AI@THINK.ARPA
Subject: Adjustable and displaced arrays
In-Reply-To: Msg of 23 May 1985 10:51-EDT from Guy Steele <gls%AQUINAS at THINK.ARPA>
I'm still not sure we have communicated here. My specific concern
is that if I am interpreting you intent correctly, the implementation
of complex arrays in Spice Lisp (and derived implementations) is
seriously flawed.
Spice Lisp implements complex arrays as a header which contains,
among other things, a pointer to the one-dimensional simple-array
which actually holds tha data, and the displaced-index-offset. When a
displaced array is made, the data vector is the data vector of the
original array, and the offset is set appropriately.
With this representation displacement is handled with minimal
additional overhead. The problem is that the header for the displaced
array contains the pointer to the actual data vector for the original
array. If the original array is adjusted, the aliasing will be lost.
If this implementation is indeed incorrect, what is the correct
implementation?
Rob
∂23-May-85 1113 DLW@SCRC-STONY-BROOK.ARPA Re: Backquote idioms
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 May 85 11:13:13 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242733; Thu 23-May-85 14:08:26-EDT
Date: Thu, 23 May 85 14:09 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Re: Backquote idioms
To: DCP@SCRC-QUABBIN.ARPA, smh@MIT-EDDIE.ARPA, KMP@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850522164152.8.NFEP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <850523140903.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
Reply-To: dlw@SCRC-STONY-BROOK.ARPA
Date: Wed, 22 May 85 16:41 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
I am not saying that 69 levels of backquote should not be defined. I am
saying that it should not be encouraged for people writing programs.
I rather doubt that any users, upon seeing the explanation in the manual,
will then rush to their terminals so use triple-nested backquotes. It's
not something that people will be "encouraged" to use; in fact, most people
will have a very hard time figuring out why you'd ever use it. So I don't
think there's much to worry about.
∂23-May-85 1336 DCP@SCRC-STONY-BROOK.ARPA Adjustable and displaced arrays
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 May 85 13:36:17 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242854; Thu 23-May-85 16:35:44-EDT
Date: Thu, 23 May 85 16:37 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Adjustable and displaced arrays
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12113193061.BABYL@CMU-CS-C.ARPA>
References: <RAM.12113193061.BABYL@CMU-CS-C.ARPA>,
The message of 23 May 85 09:57-EDT from greek@DEC-HUDSON
Message-ID: <850523163729.9.NFEP@NEPONSET.SCRC.Symbolics.COM>
For references, the following describes how Lisp Machines do displacing.
If array a is created displaced to array b, then there are two items of
interest in this relationship. (1) Array a is holding onto array b, and
array a has a number stored in it which is the offset into b.
If array b is then adjusted, nothing "physically" happens to array a.
Array a still is still holding onto array b and still has the same
offset within b, independent of what b looked like before and after b
was adjusted.
I order for a to be >>meaningfully displaced<< to b, especially when b
has been adjusted, the rules of row major storage must be taken into
account. By the above description, people programming LispMs need to
beware, not the people implementing CL for LispMs.
∂23-May-85 1456 RPG Yellow pages
∂21-May-85 0010 GRISS%hp-hulk.csnet@csnet-relay.arpa Yellow pages
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 21 May 85 00:10:44 PDT
Received: from hplabs by csnet-relay.csnet id ad18529; 21 May 85 3:00 EDT
Received: by HP-VENUS id AA16145; Mon, 20 May 85 20:38:46 pdt
Resent-Message-Id: <8505210338.AA16145@HP-VENUS>
Message-Id: <8505210338.AA16145@HP-VENUS>
Mail-From: GRISS created at 20-May-85 20:38:01
Date: Mon 20 May 85 20:38:00-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Yellow pages
To: fahlman@cmu-cs-c.ARPA
Cc: GRISS@hplabs.CSNET
Resent-Date: Mon 20 May 85 20:38:23-PDT
Resent-From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Resent-To: rpg@su-ai.ARPA
Source-Info: From (or Sender) name not authenticated.
Scott:
I picked up the CATLOG.TXT. Thanks. I was a bit disappointed to see
how little "portable" code there was; HIST and TIMING were all I saw.
Is catalog up todate? What else could be released?
M
-------
∂23-May-85 1539 STEINER@RUTGERS.ARPA Re: Does FORMAT handle multiple values
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 23 May 85 15:38:51 PDT
Received: from RUTGERS.ARPA (rutgers-gw.ARPA) by THINK.ARPA id AA09073; Thu, 23 May 85 18:32:45 edt
Date: 23 May 85 18:32:54 EDT
From: Dave <Steiner@RUTGERS.ARPA>
Subject: Re: Does FORMAT handle multiple values
To: gls%AQUINAS@THINK.ARPA, RAM@CMU-CS-C.ARPA
Cc: Common-Lisp%SU-AI.ARPA@THINK.ARPA
In-Reply-To: Message from "Guy Steele <gls%AQUINAS@THINK.ARPA>" of 17 Nov 1858 13:01:42 EST
Date: Thu, 23 May 1985 04:57 EDT
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Subject: Does FORMAT handle multiple values
Date: Thursday, 23 May 1985 04:30-EDT
From: Dave <Steiner at RUTGERS.ARPA>
To: Common-Lisp at SU-AI.ARPA
Re: Does FORMAT handle multiple values
(format t "~S~%" (progn ... (values ...)))
I'm not sure what you think that code is supposed to do, but there are
two ways that I can think of to turn MV's into format arguments (or
any other kind of arguments). You can use Multiple-Value-List (not
values-list, as you said)
Oops, I always mix up Values-List and Multiple-Value-List. Obviously
need a TWIM (Type What I Mean :-)).
to get a list, or you can use
Multiple-Value-Call.
What I'm doing is generating a bunch of test cases for random
functions, ie (format t "~S~%" (foo ...)). I'd rather not have to do
a Multiple-Value-List around everything for the few times that
something returns MVs. I was hoping that format could handle
multiple values in some way that I wouldn't have to know if I was
dealing with MVs or not. Doesn't look like it. Oh well.
In Common Lisp, there is no user-visible distinction between returning
one value and returning one "multiple value", so the
multiple-value-### primitives will work fine even if only one value is
being returned.
Rob
Date: Thursday, 23 May 1985, 10:43-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Does FORMAT handle multiple values
Date: 23 May 85 04:30:24 EDT
From: Dave <Steiner@RUTGERS.ARPA@think>
Does format handle multiple values at all? What I want to do is
something like the following (only this throws away everything but
the first value):
(format t "~S~%" (progn ... (values ...)))
I would write this as
(multiple-value-call #'format t "~S~%" (progn ... (values ...)))
In this case you either have to know how many values you are going to
be returning or use the iteration directive in the format string. If
you type this in as written (assuming that you get more than one
value back from values), you only get one value printed.
thereby causing multiple values from each argument form to be
"spread out" as separate arguments to FORMAT.
--Guy
Oh well, looks like I'm going to have to have a separate case for
MVs. thanks anyway.
ds
uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner
arpa: Steiner@RUTGERS
-------
∂23-May-85 1819 GSB@MIT-MC Get-Setf-Method
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 May 85 18:19:33 PDT
Date: Thu, 23 May 85 21:17:35 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: Get-Setf-Method
To: RAM@CMU-CS-C
cc: common-lisp@SU-AI
Message-ID: <[MIT-MC].516353.850523.GSB>
Date: Thu, 23 May 1985 08:03 EDT
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Get-Setf-Method should take an (optional?) environment argument so
that it can expand macros correctly.
I pointed this out months ago, and i thought we had established this
as a given.
∂23-May-85 2022 DLW@SCRC-STONY-BROOK.ARPA Fahlman's comments
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 May 85 20:21:59 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 243087; Thu 23-May-85 23:21:08-EDT
Date: Thu, 23 May 85 23:21 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Fahlman's comments
To: RPG@SU-AI.ARPA, quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA,
squires@USC-ISI.ARPA
In-Reply-To: The message of 9 May 85 01:46-EDT from Dick Gabriel <RPG@SU-AI.ARPA>
Message-ID: <850523232152.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Reply-To: dlw@SCRC-STONY-BROOK.ARPA
Date: 08 May 85 2246 PDT
From: Dick Gabriel <RPG@SU-AI.ARPA>
The point of keeping (some) of the validation code `secret' is to
make sure that people don't cheat and get exactly the validation
code to work. I believe that is approximtely owow ADA is done.
Just for the record, I belive that starting with this year's test suite,
the ADA people got rid of the secret part. I don't know why (though I
have suspicions that the reason was not technical). I think I agree
with you that having a secret part to keep people honest is a good idea
and doesn't really incur substantial extra expense.
∂23-May-85 2302 GSB@MIT-MC Re: Adjustable and displaced arrays
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 May 85 23:02:26 PDT
Date: Fri, 24 May 85 02:01:24 EST
From: Glenn S. Burke <GSB@MIT-MC>
Sender: GSB0@MIT-MC
Subject: Re: Adjustable and displaced arrays
To: RAM@CMU-CS-C
cc: common-lisp@SU-AI
Message-ID: <[MIT-MC].516737.850524.GSB0>
It sounds like NIL implements complex arrays in a somewhat similar
manner to Spice Lisp. However, in the general case, the complex array
header might have to point to another complex array header. As a
result an AREF might have to iterate to find the eventual data vector.
Only in the case where none of the involved arrays (other than the
outermost) are adjustable can the data vector be "cached" as your
implementation does.
For instance.
(setq c (make-array '(5 5) :adjustable t))
C is a complex array header, whose displaced-to field (like your data
vector) is a simple vector 25 long, and whose displaced-index-offset
field holds 0.
(setq b (make-array 20 :displaced-to c :displaced-index-offset 5))
B is a complex array header, whose displaced-to field is C, because C is
adjustable, and its data vector might get thrown out and replaced by a
new one.
(setq a (make-array '(3 3) :displaced-to b :displaced-index-offset 4))
A is a complex array header, whose displaced-to field is C. It is NOT
B, because B is not adjustable, so can be optimized out. Its
displaced-index-offset field is 4, which was obtained by adding its
own with B's.
(aref A i j) operates by computing a row-major-order index into A,
using the dimensionality of A. Then (because this is a complex array)
the displaced-index-offset (9) is added to this, and that is used as a
row-major-order index into its displaced-to array, C. C is itself a
complex array, so the process iterates once more. C's
displaced-index-offset is 0 and its displaced-to happens to be just a
simple vector.
--------------
Moon and i discussed this specification some well over a year ago,
because i was somewhat disturbed at the efficiency penalty in some of
the displacement. We pretty much decided that in spite of the hair
needed, this model of array displacement was reasonable, and at least
simple arrays can be crunched pretty efficiently. (The point being
that i was somewhat put off by the implementation necessary.) In NIL,
the sequence functions operate internally by reducing a sequence to a
simple sequence and an offset, and then crunch on the simple sequence.
So, for instance, doing REPLACE on two strings, no matter how
adjustable or displaced, will eventually use the vax MOVC3
instruction, as implemented by a primitive which moves "bytes" from
one simple binary data object to another (the same thing works on
bignums).
The one thing i do NOT like about the specification is how elements
are preserved by adjust-array. The replacement of those things with
matching indices is pretty random, and pretty inefficient to boot. It
should just preserve the row-major-order data insofar as that is
possible (truncating, or extending with some initial-element or
"undefined" value, depending on whether the total-size is being
decreased or increased).
∂24-May-85 0909 DLW@SCRC-STONY-BROOK.ARPA Rules of the game
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 24 May 85 09:09:39 PDT
Received: from SCRC-STONY-BROOK.ARPA (scrc-stony-brook.arpa.ARPA) by THINK.ARPA id AA14729; Fri, 24 May 85 12:05:52 edt
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 243338; Fri 24-May-85 11:53:16-EDT
Date: Fri, 24 May 85 11:54 EDT
From: Daniel L. Weinreb <DLW%TENEX.SCRC.Symbolics.COM@THINK.ARPA>
Subject: Rules of the game
To: gls%AQUINAS@THINK.ARPA, common-lisp%SU-AI@THINK.ARPA
In-Reply-To: <850523111007.4.GLS@YON.ARPA>
Message-Id: <850524115418.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Reply-To: dlw@SCRC-STONY-BROOK.ARPA
I agree with all of this, except for point 3 (Compatible extensions),
which I think is somewhat dubious. Accepting this point means that we
can sit here and add feature after feature. Anyone comtemplating
supporting Common Lisp will have to be told "Not only do you have to
implement everything in this book, but there will probably be a steady
stream of new features that you are REQUIRED to implement, lest some
guaranteed-white-pages-compatible program not be able to run on your
system." Is that really fair to the world?
A great deal of discussion on this mailing list has been related to
things that certainly do not fall within the domains of points 1, 2, 4,
and 5. I think our time would be far better spent on those points than
on designing a new version of Common Lisp. I agree with Fateman's
general point about CL '84 and CL '86, and I think we should spend our
time where it is most urgently needed: on CL '84.
∂24-May-85 0955 GRISS%hp-hulk.csnet@csnet-relay.arpa Addendum/Erratum
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 24 May 85 09:55:12 PDT
Received: from hplabs by csnet-relay.csnet id ab11256; 24 May 85 12:32 EDT
Received: by HP-VENUS id AA18809; Fri, 24 May 85 05:50:52 pdt
Message-Id: <8505241250.AA18809@HP-VENUS>
Date: Fri 24 May 85 05:50:26-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Addendum/Erratum
To: common-lisp@su-ai.ARPA
Cc: GRISS@hplabs.CSNET
Source-Info: From (or Sender) name not authenticated.
Are there plans to publish an Erratum or Addendum sheet to go with the
current CL ref manual. Is someone gathering and editing the
various comments and elucidations submitted since the book appeared.
M
-------
∂24-May-85 1030 gls%AQUINAS@THINK.ARPA Rules of the game and stability
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 24 May 85 10:29:57 PDT
Received: by THINK.ARPA with CHAOS id AA15759; Fri, 24 May 85 13:19:06 edt
Date: Friday, 24 May 1985, 13:19-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Rules of the game and stability
To: common-lisp%sail@THINK.ARPA
Cc: gls%AQUINAS@THINK.ARPA
Message-Id: <850524131942.2.GLS@ELIGIUS.ARPA>
I agree with Fateman that Common Lisp should not be regarded as frozen
forever and that there can be staged versions of it as for FORTRAN. I
do think that two years is too short a cycle, however; given LISP's
history of instability, large changes to Common Lisp over only two
years will simply look like more of the same chaos. Hedrick's point
is also well taken that by 1986 a lot of people will barely have
finished implementing CL'84.
On the other hand, FORTRAN's revisions run on an 11-year cycle, which
I think is much too long. If I had to make a projection today (and I
will; here it comes, ta da), I would say that the time for a major
"version change" to Common Lisp will be ripe about 1988 or 1989, and
there is room for a "corrected edition" of CL'84 in about 1986 (I
think it will take about another year to discuss the outstanding and
new issues raised since the book was published a year ago, decide what
to do, change the book, and get the new edition published).
I agree with DLW that my category (3) should be regarded with caution,
if not suspicion; my examples were not well chosen. I am not
recommending the introduction of flavors in the near future, for
example. I was ordering the categories according to user disruption,
not implementation disruption, and of course both are important.
A small number of things like &body won't hurt, but we don't want
to introduce a hundred new functions.
Someone referred to my previous note with the word "policy". I would
like to say that I am not attempting to establish policy unilaterally.
I am trying to summarize my sense of what everyone seems to want,
colored of course by my opinions as to what I think would be best for
everyone concerned. (It might be useful for everyone to understand
that right now I am more a user of Common Lisp than an implementor!
On the other hand, part of my work here at Thinking Machines is
concerned with implementing a sideset of Common Lisp for parallel
processing.)
--Guy
∂24-May-85 1300 gls%AQUINAS@THINK.ARPA Addendum/Erratum
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 24 May 85 13:00:30 PDT
Received: by THINK.ARPA with CHAOS id AA17473; Fri, 24 May 85 15:55:21 edt
Date: Friday, 24 May 1985, 15:55-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Addendum/Erratum
To: common-lisp%su-ai@THINK.ARPA
Cc: GRISS%hplabs.CSNET@THINK.ARPA, gls%AQUINAS@THINK.ARPA
In-Reply-To: <8505241250.AA18809@HP-VENUS>
Message-Id: <850524155541.1.GLS@DESIDERIUS.ARPA>
I have been collecting changes that I believe to be non-controversial
into one place. I also keep track of all Common Lisp mail. Now that
discussions have been revving up again on this mailing list, I would
like later this summer to gather up the discussions, make up another
ballot, and conduct a poll on proposed changes. The results of this
poll must, I suppose, be considered provisional until we come up with an
organizational charter.
Appended to this message is my list of non-controversial changes.
----------------------------------------------------------------
Corrections to first printing of Common Lisp: The Language
10 First two paragraphs should have monospace comma and colon,
respectively, at the left margin.
18 3.1010299957f-1 should be 3.010299957f-1 (first "1" should be deleted).
43 Table 43-1 should include the names "signed-byte" and "unsigned-byte".
67 The comment in (defun discriminant ...) is wrong, because the code
works for complex coefficients. Change the line
The quadratic equation a*x↑2+b*x+c=0 has real, multiple
to be the two lines
If the coefficients a, b, and c are all real numbers, then
the quadratic equation a*x↑2+b*x+c=0 has real, multiple
69 Top line, last word but one, should be "replace", not "replaces".
99 In first line of second paragraph, delete the italicized word "newvalue".
145 Three lines from the bottom, the term "&environment" should
appear at the left in monospace.
147 Last line on this page should be deleted; it duplicates first line
on page 148.
157 In third line, "declaration-form" should be "decl-spec" (in italics).
200 At the end of the first paragraph "returns the result." add the sentence
"It is an error if any argument other than the first is zero."
After "With one argument, / reciprocates the result" add the sentence
"The argument must not be zero."
204 Halfway down, the last line of a paragraph "#C(0.5 1.73205)."
should say "#C(1.0 1.73205)."
216 Alter "The divisor may be any non-complex number." to read
"The divisor may be any non-zero non-complex number."
216 Change "For example, (floor 5 2) @EQ (floor (/ 5 2)) ..." to
"For example, (values (floor 5 2)) @EQ (values (floor (/ 5 2))) ...".
216 Before last paragraph, insert this new paragraph:
Note that while (floor 5 2) and (floor (/ 5 2)) return the same first
value, they return different remainders as the second value:
(floor 5 2) => 2 1
(floor (/ 5 2)) => 2 1/2
This is why @f[values] was used above in the remark that
(values (floor 5 2)) @EQ (values (floor (/ 5 2))).
276 Halfway down, in the display line before "See pushnew.", the phrase
"(fn item)" should be "(funcall fn item)", with "funcall" in monospace
and "fn" and "item" in italics as before.
307 In the header line for "defstruct", "{slot-description}+" should
be "{slot-description}*" (star instead of plus).
309 First paragraph should end "see section 19.6)." not "see section 19.6.";
there is a missing parenthesis.
325 The name of the variable "-" does not appear in the header line.
347-348 The page layout is a bit confused here; some connection should
be made between the description of ";" and the example.
349 Before the first complete paragraph, there should be a heading
line consisting of a single monospace backquote (accent grave).
349 In the first example of the use of backquote, the character
just before " (print ,x)" is a "t". (It is badly printed in several
copies.)
373 Third line from bottom: "print-array" in monospace should
be "*print-array*".
454 In index entry for "defun", first page number should be 67, not 57.
458 In index entry for "macrolet", page numbers should be 113-114 instead
of 93-94.
465 "zerop" is missing from the index (it is defined on page 195).
458 First reference for "macrolet" should be 113-114, not 93-94.
459 Add index entry "newline 20, 21-22, 235, 243, 336, 347, 378, 383, 384,
397".
∂27-May-85 1105 RAM@CMU-CS-C.ARPA Does Defmacro establish a block?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 May 85 01:30:09 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 27 May 85 04:30:09-EDT
Date: Mon, 27 May 1985 04:30 EDT
Message-ID: <RAM.12114291388.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Does Defmacro establish a block?
Comment: Remailed after delay caused by distribution list error at SU-AI.
Does defmacro establish a named block around the definition the
same way that defun does? CLTL doesn't mention this issue at all,
leading one to suppose that it doesn't, but this seems to create a
pointless inconsistency with defun.
If defmacro does, do define-setf-method, defsetf, deftype...?
Rob
∂27-May-85 1225 DLW@SCRC-STONY-BROOK.ARPA Does Defmacro establish a block?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 May 85 12:25:41 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 244204; Mon 27-May-85 15:24:36-EDT
Date: Mon, 27 May 85 15:26 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Does Defmacro establish a block?
To: RAM@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12114291388.BABYL@CMU-CS-C.ARPA>
Message-ID: <850527152627.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Reply-To: dlw@SCRC-STONY-BROOK.ARPA
Date: Mon, 27 May 1985 04:30 EDT
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Does defmacro establish a named block around the definition the
same way that defun does?
I know you're asking about the definition of CL, and I don't have
anything to add about that, but I thought you might be interested to
know that it does in our implementation.
∂28-May-85 0742 greek@DEC-HUDSON Rules of the Game
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 28 May 85 07:41:41 PDT
Date: Tue, 28 May 85 10:41:47 EDT
From: greek@DEC-HUDSON
Subject: Rules of the Game
To: common-lisp@su-ai
I'm glad we are taking time to establish a "policy" about making
changes to CL'84. Regarding Guy's categories 3 and 4, I think we
should only introduce new features when they are necessary to repair
a (more or less) flawed feature in the language. For example,
PARSE-BODY is needed by every correct implementation, so indeed
we might as well specify it. Incompatible changes should only
be made when absolutely necessary to fix a broken feature.
New features and incompatible changes which do not fall into the
above category should be left for CL'8n. As Guy said, we ought to
give everyone a half a chance to finish implementing CL'84 before
we throw a pile of new good stuff at them. Remember, CLs that are
real products can't be changed continuously, because real products
change in cycles (often as long as a year or two).
- Paul
∂28-May-85 0822 greek@DEC-HUDSON Adjusting displaced arrays.
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 28 May 85 08:21:49 PDT
Date: Tue, 28 May 85 11:21:20 EDT
From: greek@DEC-HUDSON
Subject: Adjusting displaced arrays.
To: common-lisp@su-ai
Erf! I certainly should have objected to the incredible hair needed
to implement adjustable arrays, particularly those which are displaced,
back when we specified them. However, I'd like to object now.
I'd like to see a list of the uses people make of displaced and
adjustable arrays. Maybe there are only two or three real features
that people use, and we could restrict ourselves to those. I looked
around here at DEC, and found exactly two uses:
1. Make an array bigger. Obviously this could be done with MAKE-ARRAY
and REPLACE.
2. Linearize a multidimensional array so that row-major references
can be done. This is useful, but an AREF-ROW-MAJOR function could
probably do it more efficiently.
It seems to me that any set of rules that require AREF to iterate to
find the data ought to be simplified. So much for inline code.
- Paul
∂28-May-85 0946 DCP@SCRC-STONY-BROOK.ARPA Adjusting displaced arrays.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 May 85 09:46:29 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 244606; Tue 28-May-85 12:46:07-EDT
Date: Tue, 28 May 85 12:48 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Adjusting displaced arrays.
To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 28 May 85 11:21-EDT from greek@DEC-HUDSON
Message-ID: <850528124820.3.NFEP@NEPONSET.SCRC.Symbolics.COM>
Date: Tue, 28 May 85 11:21:20 EDT
From: greek@DEC-HUDSON
Erf! I certainly should have objected to the incredible hair needed
to implement adjustable arrays, particularly those which are displaced,
back when we specified them. However, I'd like to object now.
I'd like to see a list of the uses people make of displaced and
adjustable arrays. Maybe there are only two or three real features
that people use, and we could restrict ourselves to those. I looked
around here at DEC, and found exactly two uses:
1. Make an array bigger. Obviously this could be done with MAKE-ARRAY
and REPLACE.
2. Linearize a multidimensional array so that row-major references
can be done. This is useful, but an AREF-ROW-MAJOR function could
probably do it more efficiently.
LispMs (which include Symbolics, and I believe LMI and TI for this
discussion) use displaced arrays for at least the following:
NSUBSTRING (which is SUBSTRING, but shares storage)
bitmaps (both for creating subwindows of windows, and for
redirecting an array (a) to a physical screen or (b) to
a bit save array.)
de/en-capsulating network packets (e.g., the data of a packet is a
string that shares storage with the packet; the string
starts after the protocol header.)
I don't think we don't use it for your case (1); instead we do make a
new array, copy, and structure forwared the old to the new. They can
also be used for your case (2), but I think the our function
SYS:%1D-AREF subsumes the need.
It seems to me that any set of rules that require AREF to iterate to
find the data ought to be simplified. So much for inline code.
∂28-May-85 1439 masinter.pa@Xerox.ARPA programs writing backquote
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 28 May 85 14:38:51 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 28 MAY 85 14:38:55 PDT
Date: 28 May 85 14:38 PDT
From: masinter.pa@Xerox.ARPA
Subject: programs writing backquote
To: common-lisp@su-ai.ARPA
Message-ID: <[]<>MG>Q>Item-850528-143855-1480@Xerox>
In part of the discussion over nesting depth of backquote, more than one
person alluded to the possibility that a *program* could write a 3-deep
nested backquote and that this was generally a good thing.
However, as far as I can tell, it would be easier for a Snobol program
to write nested backquotes rather than Lisp, because there is no defined
S-expression representation of backquotes... the only thing GSSB ( Guy
Steele's Silver Book) defines is the surface syntax.
Do I misunderstand? Can someone give a program which creates a Common
Lisp 3-deep-nested backquote, without resorting to string manipulations?
∂28-May-85 1450 masinter.pa@Xerox.ARPA Re: Rules of the game and stability
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 28 May 85 14:50:31 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 28 MAY 85 14:46:36 PDT
Date: 28 May 85 14:46 PDT
From: masinter.pa@Xerox.ARPA
Subject: Re: Rules of the game and stability
To: common-lisp@SU-AI.ARPA
cc: common-lisp-charter@su-ai.ARPA
Message-ID: <[]<>MG>Q>Item-850528-144636-1487@Xerox>
Isn't this what the "charter" committee is supposed to be deciding? I've
not seen much action on CLCHRT.MSG -- is there more happening
behind-the-scenes?
∂28-May-85 1515 KMP@SCRC-STONY-BROOK.ARPA programs writing backquote
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 May 85 15:15:03 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 244953; Tue 28-May-85 18:14:34-EDT
Date: Tue, 28 May 85 18:14 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: programs writing backquote
To: masinter.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[]<>MG>Q>Item-850528-143855-1480@Xerox>
Message-ID: <850528181434.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 28 May 85 14:38 PDT
From: masinter.pa@Xerox.ARPA
In part of the discussion over nesting depth of backquote, more than one
person alluded to the possibility that a *program* could write a 3-deep
nested backquote and that this was generally a good thing.
However, as far as I can tell, it would be easier for a Snobol program
to write nested backquotes rather than Lisp, because there is no defined
S-expression representation of backquotes... the only thing GSSB ( Guy
Steele's Silver Book) defines is the surface syntax.
Do I misunderstand? Can someone give a program which creates a Common
Lisp 3-deep-nested backquote, without resorting to string manipulations?
The program that manipulates the common lisp does not itself have to be
written in common lisp. (eg, we've already conceded you can't write a real time
editor in common lisp, but that doesn't free us from the constraint that
common lisp code must be editable...)
In fact, the programs that I have which manipulate common backquote structure
are written in Zetalisp and they make assumptions about the internal representation
of backquoted structure.
However, all that aside, it is completely trivial to write a common lisp program
which has its own readtable and its own representation for backquoted structure
and whose sole job in life is to read in expressions, frob their backquoted
structure using its private representation, and write them back out.
... not to mention manipulating the expression at the text level -- such as
using just c-m-K and c-Y in Emacs to move a doubly nested backquote expression
inside a macro which already has a level of backquote ... something I do all
the time without the aid of any tools fancier than Emacs...
∂28-May-85 1532 MASINTER@SUMEX-AIM.ARPA (duplicate) programs writing backquote
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 28 May 85 15:32:24 PDT
Date: Tue 28 May 85 15:32:25-PDT
From: Larry Masinter <MASINTER@SUMEX-AIM.ARPA>
Subject: (duplicate) programs writing backquote
To: common-lisp@SU-AI.ARPA
I've gotten back about twenty "Unable to deliver" messages because of a new
"message-id" that our local mail-handler started adding. I'm
repeating the message here -- sorry if it is a duplicate.
Date: 28 May 85 14:38 PDT
From: masinter.pa@Xerox.ARPA
Subject: programs writing backquote
To: common-lisp@su-ai.ARPA
Message-ID: <[]<>MG>Q>Item-850528-143855-1480@Xerox>
In part of the discussion over nesting depth of backquote, more than one
person alluded to the possibility that a *program* could write a 3-deep
nested backquote and that this was generally a good thing.
However, as far as I can tell, it would be easier for a Snobol program
to write nested backquotes rather than Lisp, because there is no defined
S-expression representation of backquotes... the only thing GSSB ( Guy
Steele's Silver Book) defines is the surface syntax.
Do I misunderstand? Can someone give a program which creates a Common
Lisp 3-deep-nested backquote, without resorting to string manipulations?
-------
∂29-May-85 0005 REM@IMSSS
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-May-29 23:02:12 PST (=GMT-8hr)
Date: 1985 May 28 22:56:08 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132206061364.G0353
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:masinter.pa@Xerox.ARPA
CC:COMMON-LISP@SU-AI.ARPA
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up)
> Date: 28 May 85 14:38 PDT
> From: masinter.pa@Xerox.ARPA
> Subject: programs writing backquote
>
> In part of the discussion over nesting depth of backquote, more than one
> person alluded to the possibility that a *program* could write a 3-deep
> nested backquote and that this was generally a good thing.
>
> However, as far as I can tell, ... because there is no defined
> S-expression representation of backquotes... the only thing GSSB ( Guy
> Steele's Silver Book) defines is the surface syntax.
This is curious because in PSL the ` read-macro seems to generate a
true LISP macro (i.e. an s-expression representation of the ` syntax)
which then actually implements the semantics of the ` character when
interpreted or compiled. Perhaps CL should specify something like this
explicitly? Below are examples of original PSL source and the result
of READing into memory following by PRIN1ing it back out (then
manually prettyprinting in EMACS). It seems to me quite reasonable
that a PRINter function that is smarter than PRIN1 might re-introduce
the backquote optimizations (or in complex cases find better
optimizations than given by original programmer).
(defmacro cl-alias (sl-name cl-name)
`(defmacro ,cl-name form
`(,',sl-name . ,form)))
(DEFMACRO CL-ALIAS (SL-NAME CL-NAME)
(BACKQUOTE
(DEFMACRO (UNQUOTE CL-NAME) FORM
(BACKQUOTE ((UNQUOTE (QUOTE (UNQUOTE SL-NAME)))
UNQUOTE FORM)))))
(defmacro errset (form flag)
`(errorset `,',form ,flag ,flag))
(DEFMACRO ERRSET (FORM FLAG)
(BACKQUOTE
(ERRORSET
(BACKQUOTE (UNQUOTE (QUOTE (UNQUOTE FORM))))
(UNQUOTE FLAG)
(UNQUOTE FLAG))))
∂29-May-85 0709 greek@DEC-HUDSON Internal representation of backquotes
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 May 85 07:08:44 PDT
Date: Wed, 29 May 85 10:08:47 EDT
From: greek@DEC-HUDSON
Subject: Internal representation of backquotes
To: common-lisp@su-ai
We would have to be very careful if we wanted to specify how backquotes
et al are represented when read in. In PSL, you have an explicit
form for backquote et al, but in VAX LISP the reader converts the
backquotes into the actual LISP code needed to build the backquoted
lists. So we lose all knowledge that a backquote was ever involved
(unless, of course, you turn on the magic variable that causes
us to remember).
I think we need to allow maximum flexibility in generating efficient
code for backquotes.
- Paul
∂29-May-85 1246 greek@DEC-HUDSON Internal representation of backquotes
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 May 85 07:08:44 PDT
Date: Wed, 29 May 85 10:08:47 EDT
From: greek@DEC-HUDSON
Subject: Internal representation of backquotes
To: common-lisp@su-ai
We would have to be very careful if we wanted to specify how backquotes
et al are represented when read in. In PSL, you have an explicit
form for backquote et al, but in VAX LISP the reader converts the
backquotes into the actual LISP code needed to build the backquoted
lists. So we lose all knowledge that a backquote was ever involved
(unless, of course, you turn on the magic variable that causes
us to remember).
I think we need to allow maximum flexibility in generating efficient
code for backquotes.
- Paul
∂29-May-85 1257 DCP@SCRC-STONY-BROOK.ARPA programs writing backquote
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 May 85 12:57:19 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 245299; Wed 29-May-85 10:56:43-EDT
Date: Wed, 29 May 85 10:59 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: programs writing backquote
To: masinter.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[]<>MG>Q>Item-850528-143855-1480@Xerox>
Message-ID: <850529105911.3.NFEP@NEPONSET.SCRC.Symbolics.COM>
Date: 28 May 85 14:38 PDT
From: masinter.pa@Xerox.ARPA
In part of the discussion over nesting depth of backquote, more than one
person alluded to the possibility that a *program* could write a 3-deep
nested backquote and that this was generally a good thing.
However, as far as I can tell, it would be easier for a Snobol program
to write nested backquotes rather than Lisp, because there is no defined
S-expression representation of backquotes... the only thing GSSB ( Guy
Steele's Silver Book) defines is the surface syntax.
Do I misunderstand? Can someone give a program which creates a Common
Lisp 3-deep-nested backquote, without resorting to string manipulations?
This doesn't resort to string manipulation, and it produces structure
that is more than 3 deep. It is quite contrived, but it does satisfy
your requirements. Just trying to produce this example gave me the
opinion it is hard to write meaningful programs [that write meaningful
programs...] that produce highly nested backquoted structure.
(defun print-using-backquote (exp)
(pprint (sublis '((list . si:xr-bq-list)
(cons . si:xr-bq-cons)
(list* . si:xr-bq-list*)
(append . si:xr-bq-append))
exp)))
(print-using-backquote
;; exp starts out being a constructor of an alist. The data of the
;; alist is another alist
(do ((exp '(list (list 'a (cons 'ab ab) (cons 'ac ac))
(list 'b (cons 'bb bb) (cons 'bc bc))
(list 'c (cons 'cb cb) (cons 'cc cc)))
(subst exp 'bc exp))
(count 2 (1- count)))
((zerop count) (print-using-backquote exp))))
`((A (AB .,AB) (AC .,AC))
(B (BB .,BB)
(`((A (AB .,AB) (AC .,AC))
(B (BB .,BB)
(`((A (AB .,AB) (AC .,AC))
(B (BB .,BB)
(`((A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC)))
(A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC))))
(C (CB .,CB) (CC .,CC)))
(A (AB .,AB) (AC .,AC))
(B (BB .,BB)
(`((A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC)))
(A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC))))
(C (CB .,CB) (CC .,CC))))
(C (CB .,CB) (CC .,CC)))
(A (AB .,AB) (AC .,AC))
(B (BB .,BB)
(`((A (AB .,AB) (AC .,AC))
(B (BB .,BB)
(`((A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC)))
(A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC))))
(C (CB .,CB) (CC .,CC)))
(A (AB .,AB) (AC .,AC))
(B (BB .,BB)
(`((A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC)))
(A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC))))
(C (CB .,CB) (CC .,CC))))
(C (CB .,CB) (CC .,CC))))
(C (CB .,CB) (CC .,CC)))
∂29-May-85 1257 DLW@SCRC-STONY-BROOK.ARPA Re: Rules of the game and stability
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 May 85 12:57:29 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 245277; Wed 29-May-85 10:46:45-EDT
Date: Wed, 29 May 85 10:47 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Re: Rules of the game and stability
To: masinter.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[]<>MG>Q>Item-850528-144636-1487@Xerox>
Message-ID: <850529104747.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Reply-To: dlw@SCRC-STONY-BROOK.ARPA
Date: 28 May 85 14:46 PDT
From: masinter.pa@Xerox.ARPA
Isn't this what the "charter" committee is supposed to be deciding?
Yes, that's what I thought too.
∂29-May-85 1445 gls@AQUINAS.ARPA Re: Rules of the game and stability
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 29 May 85 14:45:49 PDT
Received: by THINK.ARPA with CHAOS id AA17733; Wed, 29 May 85 17:23:35 edt
Date: Wed, 29 May 85 17:24 EDT
From: Guy Steele <gls@AQUINAS.ARPA>
Subject: Re: Rules of the game and stability
To: common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS.ARPA
In-Reply-To: <850529104747.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <850529172430.3.GLS@DESIDERIUS.ARPA>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Date: Wed, 29 May 85 10:47 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM@think>
Date: 28 May 85 14:46 PDT
From: masinter.pa@Xerox.ARPA
Isn't this what the "charter" committee is supposed to be deciding?
Yes, that's what I thought too.
That's what I thought, too. When I started this whole discussion
I clearly labeled my list of "rules" as merely my opinion of what
we ought to do. The charter committee may consider that list as
input to their discussions. The charter committee must also bear
in mind that to make no decision is also a decision.
People clearly want a revised edition (or revised printing) of the
manual, or at least an errata sheet. I will do the editing work on
this, but the charter should provide guidance how to go about it. If
this doesn't happen in the next four months or so, I, radical fanatic
that I am, may just go ahead and conduct a poll as we have done before
and go from there, simply to get something done. However, I would
rather have an agreed-upon structure in place to work within before
this time comes.
--Guy
∂31-May-85 0926 DCP@SCRC-STONY-BROOK.ARPA CLtL Index
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 31 May 85 09:26:01 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 246905; Fri 31-May-85 12:25:18-EDT
Date: Fri, 31 May 85 12:28 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: CLtL Index
To: common-lisp@SU-AI.ARPA
Message-ID: <850531122824.9.NFEP@NEPONSET.SCRC.Symbolics.COM>
CLtL's index doesn't have &anything either at the beginning or the end
(with the other non-alphabetics). I therefore can't look up &KEY, etc,
since they aren't listed under their non-& names.
∂31-May-85 1440 hplabs!perdue%hplabs.csnet@csnet-relay.arpa Re: Programs writing backquote
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 31 May 85 14:40:04 PDT
Received: from hplabs by csnet-relay.csnet id ag02308; 31 May 85 17:35 EDT
Received: by HP-VENUS id AA09296; Fri, 31 May 85 13:00:59 pdt
Message-Id: <8505312000.AA09296@HP-VENUS>
Date: 31-May-85 12:58:47
To: common-lisp@su-ai.ARPA
Subject: Re: Programs writing backquote
From: perdue%hplabs.csnet@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
I'd like to second the proposal that Common LISP backquote "`" be
explicitly defined as expanding into a macro, and that ",", ",@", and
",." expand similarly into s-expression forms. This makes backquote
more accessible to programs. The point has been made that if "`"
expands into a LISP macro invokation, a conventional interpreter will
run the code relatively slowly. This kind of objection of course
applies to use of macros in general, and I don't think we usually let
it stop us from defining macros where they are useful.
-------
∂02-Jun-85 0802 FAHLMAN@CMU-CS-C.ARPA Programs writing backquote
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Jun 85 08:02:33 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 2 Jun 85 11:02:19-EDT
Date: Sun, 2 Jun 1985 11:02 EDT
Message-ID: <FAHLMAN.12115935645.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: perdue%hplabs.csnet@CSNET-RELAY.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Programs writing backquote
In-reply-to: Msg of 31 May 1985 12:58-EDT from perdue%hplabs.csnet at csnet-relay.arpa
I'd like to second the proposal that Common LISP backquote "`" be
explicitly defined as expanding into a macro, and that ",", ",@", and
",." expand similarly into s-expression forms. This makes backquote
more accessible to programs. The point has been made that if "`"
expands into a LISP macro invokation, a conventional interpreter will
run the code relatively slowly. This kind of objection of course
applies to use of macros in general, and I don't think we usually let
it stop us from defining macros where they are useful.
If we really want to do this, it should be sufficient to define
S-expression forms that the various backquote character macros COULD
expand into, and that programs can generate to get the same effect. We
don't have to require implementors to actually use these in processing
backquoted expressions.
Since all of these generated forms have equivalents that use only
pre-defined things like QUOTE, CONS, APPEND, and NCONC, I don't really
see much point in adding a bunch of new things that correspond directly
to the backquote forms. Programs can just say what they really mean,
without having to try to think in terms of these cute surface-level
forms that happen to be convenient for humans.
-- Scott
∂02-Jun-85 1058 FAHLMAN@CMU-CS-C.ARPA Rules of the game and stability
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Jun 85 10:58:18 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 2 Jun 85 13:58:26-EDT
Date: Sun, 2 Jun 1985 13:58 EDT
Message-ID: <FAHLMAN.12115967697.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Guy Steele <gls%aquinas@THINK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Rules of the game and stability
In-reply-to: Msg of 29 May 1985 17:24-EDT from Guy Steele <gls at AQUINAS.ARPA>
The charter committee has indeed been too inactive of late, and even
when we were active we were concentrating more on organizational issues
than on the proper philosophy for stability versus fixing things. I'll
try to fire this discussion up again, once I get finished with some
immediate demands on my time. I sort of put things on hold until we all
could get some idea of what services the DARPA/ISI contract was going to
provide, and when.
I agree with Guy's list of the kinds of changes that might be
considered, in increasing order of disruptiveness. I would only add
that there is a lot of variation in each of these categories: an
incompatible change in the cut points of obscure trig functions is not
going to disrupt things as much as, say, an incompatible change in the
handling of special variables. Additions to the language are not a
burden if accompanied by portable code that implements the addition.
Other additions might not be implementable in a portable way, but would
obviously require only very minor and local changes to implement.
I also agree that Common Lisp 84 should be considered frozen in the way
that Guy proposes: only compatible or absolutely essential changes
should be made at this point. There should be no fundamental additions
to Common Lisp 84 either, though there is no harm in putting together a
body of quasi-standard code that can be trivially added to any complete
and correct implementation, with the understanding that these features
go into the base language the next time around. Library files could
begin assuming the existence of these additions right now.
But having said that, I should also say that the language as it stands
is still very young, relatively untried, and full of known flaws. We
should therefore allow for a reasonably fast evolution at the start. I
think that for the next few years, it would be optimal to an updated
specification appear every year, or at most every two years. I
certainly don't want to wait until 1989 or whenever in order to fix the
small but important problems that we've already identified.
I'm not talking about a major upheaval every year -- I'm sure that we
will carefully weigh the benefit of each change against the cost both to
users and implementors -- but once we've decided that a change is worth
making, we should not have to wait too long for the next release cycle
to come around. At any time, there will be one well-defined version of
Common Lisp that corresponds to the latest official release, and another
that includes the changes that have been approved for the next future
release. Nobody would be required to track the latter until the release
date rolls around, but some of us (in universities, maybe) should
install any such changes right away in order to verify that they do
their job as intended.
In any event, I think we should be aiming for another release as early
as possible in 1986, and the incompatible changes we have been
discussing should be considered to be proposals for that next release.
-- Scott
∂02-Jun-85 1220 FAHLMAN@CMU-CS-C.ARPA Get-Setf-Method
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Jun 85 12:20:36 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 2 Jun 85 15:20:44-EDT
Date: Sun, 2 Jun 1985 15:20 EDT
Message-ID: <FAHLMAN.12115982668.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Get-Setf-Method
In-reply-to: Msg of 23 May 1985 08:03-EDT from Rob MacLachlan <RAM>
Get-Setf-Method should take an (optional?) environment argument so
that it can expand macros correctly.
Steve Handerson has pointed out that MACRO-FUNCTION also needs an
optional evironment argument, since without this we have no way of
getting hold of the expansion function for a lexically defined macro
(though we can execute this function). This may or may not be important
for normal code, but it is definitely important for writing environment
tools such as a single-stepper.
-- Scott
∂03-Jun-85 0520 JLW Explicit definition of backquote
To: Fahlman@CMU-CS-C.ARPA
CC: Perdue%hplabs@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
In-reply-to: your message of 2-Jun-85 11:02 EDT
MacLisp may have been the first implementation to use macro wrappers for the
target of the various "backquote" readmacros; it was motivated by the desire
to use the programable "prettyprinter", which had a very simple readmacroinverse
facility. The goal was to have read/print do for backquote what it was doing
for singlequote. Later, the Lispm (which had backquote first) switched from a
direct expansion into basic primitives (like, QUOTE, CONS, APPEND etc)
to the use of internal, semi-unpronouncable names which were copies of
these primitives, primarily to retain a modicum of the structure of the
original text (I don't think it succeeds in all cases, as does the pdp10
MacLisp and NIL code. By the way, MacLisp's wrapper names are also
quite unpronounceable -- but then, MacLisp has no package system.)
In defense of using eval-time macros, rather than going directly to
"efficient" primitive code, one may notice that CL requires a macro
expansion hook (CLtL, page 152), with which one may smoothly implement
the equivalent of the MacLisp MACROMEMO macro cacheing scheme [this
is somewhat equivalent to Interlisp's cacheing of expansions in the
hashtable CLISPARRAY]. With a very modest amount of time spent on
tuning the evaluator, there should be no hesitation to use macros freely
in CL; in fact, with a compile-time-only "optimizer", it's quite feasible
to retain full input syntax, while compiling something quite different,
something which has been "optimized" to the hilt.
Even a vanilla implementation, wrappers or not, for the next manual would
be of immense help, and could fullfill your suggestion:
If we really want to do this, it should be sufficient to define
S-expression forms that the various backquote character macros COULD
expand into, and that programs can generate to get the same effect. We
don't have to require implementors to actually use these in processing
backquoted expressions.
Frankly, I think such a suggestive coding, in Lisp, would be more easily
understandable than the formal specification of CLtL pages 349-351.
This may have more value than one would think at first. A few years back,
someone in the Interlisp community decided to re-invent the backquote facility
in a more "Interlispy" fashion, and spent three years getting it wrong. The
test case was some doubly-nested (not triply-nested!!) code taken from Bob
Kern's original implementation of DEFSETF for MacLisp/NIL. About every six
months, this individual would proffer yet another version of the newly-invented
substitute for backquote, and I would have to grovel over the output on the
test case to see why it was wrong. Sometimes the code produced was grossly
erroneous (unbound gensyms as free variables!) but most often it would
CONS when it should have LIST'd, or CAR when it should have CDR'd; and
the only way to check it was to compare it with the normalized form
produced by pdp10 MacLisp.
We need the CL equivalent of that MacLisp version -- a standard by which
other, alleged backquote implementations may be measured.
-- JonL --
∂03-Jun-85 0624 greek@DEC-HUDSON Programs writing backquotes
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 3 Jun 85 06:24:15 PDT
Date: Mon, 03 Jun 85 09:24:25 EDT
From: greek@DEC-HUDSON
Subject: Programs writing backquotes
To: common-lisp@su-ai
I agree with Scott. Backquote et al are shorthands for people. Programs
can (really almost) just as easily generate the real code.
- Paul
∂03-Jun-85 0710 KMP@SCRC-STONY-BROOK.ARPA Programs writing backquotes
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 3 Jun 85 07:10:24 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 247754; Mon 3-Jun-85 10:09:12-EDT
Date: Mon, 3 Jun 85 10:09 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Programs writing backquotes
To: greek@DEC-HUDSON
cc: Common-Lisp@SAIL
Message-ID: <850603100932.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Don't be silly. Programs that write programs to run maybe can generate
`real' code, but programs that write programs to read better use a
readable convention. It is not just writing convenience that leads one
to write with backquote.
Further, the issue of program-manipulation of backquote is not only one
of generation, but of intelligibility of code written by users. It should
be possible to have called vanilla READ and to get backquoted structure
and to be able to identify it as such. The grinder is an obvious example
of a program which needs to be able to recognize such things, but it would
be easy to conjure others.
∂03-Jun-85 0945 vanroggen@DEC-HUDSON read macros
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 3 Jun 85 09:45:12 PDT
Date: Mon, 03 Jun 85 12:45:17 EDT
From: vanroggen@DEC-HUDSON
Subject: read macros
To: common-lisp@su-ai
Cc: vanroggen
I agree invertibility of backquote is desired. But users can define their
own read macros. Why don't we supply a mechanism to allow users to define
inverses of read macros, and have system supplied ones also use this
mechanism, and have the pretty-printer print the inverse?
Which reminds me--there hasn't been any discussion of Waters's modification
of FORMAT and streams to do pretty printing on this mailing list. It seems
there was some accord back in September that his proposal was reasonable.
This would be a good example of a non-portable, compatible extension to
Common Lisp; we should try to agree on this now so that its future inclusion
will be easy.
---Walter
∂03-Jun-85 1925 GSB@MIT-MC.ARPA Get-Setf-Method
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Jun 85 19:25:34 PDT
Date: Mon, 3 Jun 85 22:21:23 EST
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: Get-Setf-Method
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].529174.850603.GSB>
Date: Sun, 2 Jun 1985 15:20 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Steve Handerson has pointed out that MACRO-FUNCTION also needs an
optional evironment argument, since without this we have no way of
getting hold of the expansion function for a lexically defined macro
(though we can execute this function). This may or may not be important
for normal code, but it is definitely important for writing environment
tools such as a single-stepper.
-- Scott
Yes. I don't remember why, but apparently it was important to something in
NIL. I don't think it was just the stepper. From the looks of the
sources we put this in last october or earlier.
∂05-Jun-85 1328 gls@THINK.ARPA common lisp- &environment objects
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 5 Jun 85 13:28:18 PDT
Received: by THINK.ARPA with CHAOS id AA08313; Wed, 5 Jun 85 16:24:54 edt
Date: Wednesday, 5 June 1985, 16:25-EDT
From: Guy Steele <gls@THINK.ARPA>
Subject: common lisp- &environment objects
To: common-lisp%sail@THINK.ARPA
In-Reply-To: <850605151454.3.BRADLEY@ROCK.ARPA>
Message-Id: <850605162546.1.GLS@DESIDERIUS.ARPA>
Received: from GODOT by AQUINAS via CHAOS with CHAOS-MAIL; Wed 5-Jun-85 15:18:54-EDT
Received: by THINK.ARPA with CHAOS id AA07682; Wed, 5 Jun 85 15:13:58 edt
Date: Wednesday, 5 June 1985, 15:14-EDT
From: Bradley C. Kuszmaul <BRADLEY@AQUINAS>
Subject: common lisp- &environment objects
To: gls@AQUINAS, bradley@AQUINAS
Message-Id: <850605151454.3.BRADLEY@ROCK.ARPA>
I would like to be able to save &environment objects away somewhere, but
the book is silent about whether I can do that. Symbolics does not let
me save them because they are on the stack.
-Brad
The book is silent in the question of the extent of environments as delivered
to &environment bindings in DEFMACRO, hook functions, etc. What shall we say?
--Guy
∂05-Jun-85 1904 FAHLMAN@CMU-CS-C.ARPA common lisp- &environment objects
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Jun 85 19:04:33 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 5 Jun 85 22:06:18-EDT
Date: Wed, 5 Jun 1985 22:06 EDT
Message-ID: <FAHLMAN.12116842945.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Guy Steele <gls@THINK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: common lisp- &environment objects
In-reply-to: Msg of 5 Jun 1985 16:25-EDT from Guy Steele <gls at THINK.ARPA>
The book is silent in the question of the extent of environments as delivered
to &environment bindings in DEFMACRO, hook functions, etc. What shall we say?
One false move here and we have not Lisp but Conniver. How about
requiring "dynamic" extent for environment objects, and no more? Will
that take care of the needs for macro-expansion, steppers, and so on?
True, you could imagine cute ways of using environments that outlive
their invocations, but I REALLY don't want to pay for those cute uses
with inefficiency or severe constraints on the implementor. If anyone
wants to implement Conniver in Common Lisp, I can supply the old Maclisp
code, but let's not drag down Common Lisp itself.
-- Scott
∂05-Jun-85 1921 FAHLMAN@CMU-CS-C.ARPA common lisp- &environment objects
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Jun 85 19:21:38 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 5 Jun 85 22:23:29-EDT
Date: Wed, 5 Jun 1985 22:23 EDT
Message-ID: <FAHLMAN.12116846074.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Guy Steele <gls@THINK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: common lisp- &environment objects
Actually, that was a slight overstatement. You only get CONNIVER if you
actually allow the user to make use of the environment in certain ways,
such as GO-ing to the tags it contains. There's not much harm in making
the environment object itself non-ephemeral, I suppose, as long as
people don't get the idea that you can do very much with these objects
once you exit the dynamic extent. Still, I would opt for dynamic extent
unless someone comes up with a very clear need to go with something more
difficult.
-- Scott
∂06-Jun-85 0543 JLW Degenerate array axes
To: common-lisp@SU-AI.ARPA
What does one mean by (make-array '(0 5)) ? How should it print?
(assuming that *print-array* is non-null)
The description of array printing on page 369 presumes that the array
is either single-dimensional, or else it has some (i.e., not 0) elements.
Notice how the looping part of the algorithm resets an index to 0 (not -1)
in order to try to access the "element" at index <i1 i2 ... 0 ...>.
I've looked a several CL implementations, and all fail to print such
objects in a readable manner. Furthermore, they all print the above
array exactly the same as they do (make-array '(0 10)), even though the
two arrays are not equalp [with *print-array* set to non-null].
It seems clear to me that the algorithm of page 369 does not
provide for a way to distinguish these two arrays, since the
#nA syntax deduces the contents of th dimensions list from
the :initial-contents -- but for arrays of array-total-size equal to
zero, they all have the same "initial contents" even though their
dimensions lists may assume infinitely may values.
Three possible solutions come to mind:
1) simply rule out degenerate axes as being somehow wrong -- the
only zero-element arrays must then be vectors
2) coerce all such beasts into one with all dimensions zero -- e.g.,
treat the '(0 5) and '(0 10) as if they were '(0 0); then a NIL
for the :initial-contents would be acceptable.
3) extend the print syntax of #nA so that it can specify the dimension
list exactly, and independently of the :initial-contents field.
Anyone have any ideas on this one?
-- JonL --
∂06-Jun-85 0740 gls@THINK.ARPA Degenerate array axes
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 Jun 85 07:39:56 PDT
Received: by THINK.ARPA with CHAOS id AA23798; Thu, 6 Jun 85 10:34:00 edt
Date: Thu, 6 Jun 85 10:34 EDT
From: Guy Steele <gls@THINK.ARPA>
Subject: Degenerate array axes
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK.ARPA
In-Reply-To: Your message of 6 Jun 85 08:43-EDT
Message-Id: <850606103442.4.GLS@DESIDERIUS.ARPA>
Date: 06 Jun 85 0543 PDT
From: Jon White <JLW@SU-AI.ARPA@think>
What does one mean by (make-array '(0 5)) ? How should it print?
(assuming that *print-array* is non-null)
The description of array printing on page 369 presumes that the array
is either single-dimensional, or else it has some (i.e., not 0) elements.
Notice how the looping part of the algorithm resets an index to 0 (not -1)
in order to try to access the "element" at index <i1 i2 ... 0 ...>.
Eeee-yuk! This boner is completely my fault, and I feel very bad about it,
inasmuch as I put a lot of study into how APL hackers solved this problem.
(Essentially what they do is to exhibit a NON-empty array showing typical
components, and then say "the array I'm talking about is just like this
one except that thus-and-so axes are zero". I'm not crazy about this solution,
since we don't have the same problem of prototypes [their technical term for
what you get when you take the "CAR" of an empty array] that APL does.)
I've looked a several CL implementations, and all fail to print such
objects in a readable manner. Furthermore, they all print the above
array exactly the same as they do (make-array '(0 10)), even though the
two arrays are not equalp [with *print-array* set to non-null].
It seems clear to me that the algorithm of page 369 does not
provide for a way to distinguish these two arrays, since the
#nA syntax deduces the contents of th dimensions list from
the :initial-contents -- but for arrays of array-total-size equal to
zero, they all have the same "initial contents" even though their
dimensions lists may assume infinitely may values.
Three possible solutions come to mind:
1) simply rule out degenerate axes as being somehow wrong -- the
only zero-element arrays must then be vectors
2) coerce all such beasts into one with all dimensions zero -- e.g.,
treat the '(0 5) and '(0 10) as if they were '(0 0); then a NIL
for the :initial-contents would be acceptable.
3) extend the print syntax of #nA so that it can specify the dimension
list exactly, and independently of the :initial-contents field.
Anyone have any ideas on this one?
-- JonL --
Under option (3), how about
#A<dimension-list><initial-element>
? This would provide a notation for empty arrays, as well as a concise
notation for arrays with all elements the same (EQL). For empty arrays
the initial element doesn't especially matter, so use ().
So one would have
(make-array '(0 5)) => #A(0 5)()
(make-array '(0 10)) => #A(0 10)()
Of course, this is a non-trivial extension to the language.
--Guy
∂06-Jun-85 0809 FAHLMAN@CMU-CS-C.ARPA Degenerate array axes
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 Jun 85 08:09:39 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 6 Jun 85 11:11:28-EDT
Date: Thu, 6 Jun 1985 11:11 EDT
Message-ID: <FAHLMAN.12116985877.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Guy Steele <gls@THINK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Degenerate array axes
In-reply-to: Msg of 6 Jun 1985 10:34-EDT from Guy Steele <gls at THINK.ARPA>
Guy's suggested syntax extension seems to be the best way to go, IF we
really want to handle this problem properly. I'm not sure that this
degenerate case is worth the hassle of a major syntax extension,
however. The only reason we allowed a dimension to be 0 (in a vector)
was for APL compatibility -- the argument was that we may as well make
the boundary conditions such that someone could implement APL easily in
Common Lisp. So I guess the question is whether keeping a (0 5) array
distinct from a (0 10) array during reading and printing is really
necessary for APL compatibility and, if so, whether we continue to care
about APL compatibility. Maybe the right move is to require ALL
dimensions to be > 0 and not >= 0.
-- Scott
∂06-Jun-85 1001 FAHLMAN@CMU-CS-C.ARPA Degenerate array axes
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 Jun 85 08:09:39 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 6 Jun 85 11:11:28-EDT
Date: Thu, 6 Jun 1985 11:11 EDT
Message-ID: <FAHLMAN.12116985877.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Guy Steele <gls@THINK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Degenerate array axes
In-reply-to: Msg of 6 Jun 1985 10:34-EDT from Guy Steele <gls at THINK.ARPA>
Guy's suggested syntax extension seems to be the best way to go, IF we
really want to handle this problem properly. I'm not sure that this
degenerate case is worth the hassle of a major syntax extension,
however. The only reason we allowed a dimension to be 0 (in a vector)
was for APL compatibility -- the argument was that we may as well make
the boundary conditions such that someone could implement APL easily in
Common Lisp. So I guess the question is whether keeping a (0 5) array
distinct from a (0 10) array during reading and printing is really
necessary for APL compatibility and, if so, whether we continue to care
about APL compatibility. Maybe the right move is to require ALL
dimensions to be > 0 and not >= 0.
-- Scott
∂06-Jun-85 1021 MLY@MIT-MC.ARPA Degenerate array axes -- really array printing.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Jun 85 10:20:17 PDT
Date: Thu, 6 Jun 85 11:46:27 EST
From: Richard Mlynarik <MLY@MIT-MC.ARPA>
Subject: Degenerate array axes -- really array printing.
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].532788.850606.MLY>
Date: Thu, 6 Jun 85 10:34 EDT
From: Guy Steele <gls@THINK.ARPA>
[...]
Under option (3), how about
#A<dimension-list><initial-element>
? This would provide a notation for empty arrays, as well as a concise
notation for arrays with all elements the same (EQL). For empty arrays
the initial element doesn't especially matter, so use ().
So one would have
(make-array '(0 5)) => #A(0 5)()
(make-array '(0 10)) => #A(0 10)()
Of course, this is a non-trivial extension to the language.
It is also rather ugly, in that there seem to be no other predefined
reader macros which read TWO sexps as this does, and as such this may
be a little confusing.
I suppose the other way to do this is to print
`#.(make-array '(0 5) :initial-element 'foo)'
Speaking of which, it has always struck me as sort of a shame that
there is no convenient representation for arrays other than simple
bit-vectors, simple strings, and multidimensional arrays of
element-type `t'.
It would have been nice if there had been some facility for providing
`make-array' options by way of the `#a' macro construct (excluding
`:displaced-to' and `:displaced-index-offset') but as it is one must
print `#.(make-array ...)' in order to read in an `isomorphicp' array.
Any takers for
`#a((2 5) :element-type (mod 4) :fill-pointer 2 :initial-element 3)'?!!
∂06-Jun-85 1230 greek@DEC-HUDSON Arrays with zero dimensions.
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 6 Jun 85 12:30:31 PDT
Date: Thu, 06 Jun 85 15:30:40 EDT
From: greek@DEC-HUDSON
Subject: Arrays with zero dimensions.
To: common-lisp@su-ai
Is it really of cosmic importance that we allow dimensions of zero?
We sure could invent a lot of baggage to handle it correctly, but...
- Paul
∂06-Jun-85 2212 wilensky%ucbdali@Berkeley Common LISP terminology
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 6 Jun 85 22:12:00 PDT
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.46)
id AA23236; Thu, 6 Jun 85 17:59:55 pdt
Received: by ucbdali.ARPA (4.24/4.46)
id AA19201; Thu, 6 Jun 85 18:02:59 pdt
Date: Thu, 6 Jun 85 18:02:59 pdt
From: wilensky%ucbdali@Berkeley (Robert Wilensky)
Message-Id: <8506070102.AA19201@ucbdali.ARPA>
To: common-lisp@su-ai.ARPA
Subject: Common LISP terminology
There appears to be considerable terminological confusion in Commmon LISP.
Here are two examples:
(1) The use of the terms ``binding'', ``bound'' and ``unbound''.
On p. 55 we are told variable can be ``assigned to, as by `setq' or bound,
as by `let'. '' However, a binding is defined as a particular parameter
instance (p. 36). Moreover, a special variable (and only a special
variable) can be ``unbound''. It is also rather hard to avoid saying that
a special variable is ``bound'' when it has a value, as ``boundp'' will
return true in this case.
Unfortunately, these meanings are in conflict. For example, they allow for
the case in which a variable is ``bound'' but has no ``binding'' (namely,
when the reference is to the global value); the variable can be ``unbound'',
but have a binding (as you point out, when it is ``bound'', but valueless.)
If you simply refuse to say that a variable without any bindings is bound
(even though ``boundp'' of it is true), you are then committed to saying
that it is not `bound'', not ``unbound'', and has no ``binding'' (although,
of course, it has a perfectly fine and accessible value). In addition, a
``bound variable'' appears to mean a variable that currently has a binding
(as in, ``a variable bound by `let' ''), although, of course, such a bound
variable may very well be ``unbound''.
In addition, there appears to be confusion as to whether a variable or a
binding is something that is referenced, etc. For example, p. 37 talks
about the scope and extent of special bindings, whereas p. 38 talks about
the scope and extent of special variables. it is unclear what a reference
to a variable that happens to be a parameter might be, other than a
reference to its current binding, since this is an fact the particular
instance of that paramater that is in force. For example, p. 55 talks about
``the reference ... to the variable specified by the binding''. It is not
clear how a particular instance of a parameter can specify a variable. Nor
would this seem desirable. If two different invocations of the same
function are considered to have the same variables but with different
bindings, then one would not want to reference any variable, but rather, the
current bindings of those variables.
I could go on, but I think you get the point.
Here are some suggestions:
(1) Drop the notion of binding altogether. I think this is really an old
implementation artifact. Instead, say that every APPLICATION of a lambda
form creates new variables for its formal parameters. Also, every symbol
has a global variable associated with it. A variable may have a value, or
it may be valueless. A variable has an extent and a scope.
Introduce the function ``assignedp'', which meets the current description of
``boundp''. ``setq'' changes the value of a variable through
``assignment''. Lambda application creates a new variable and assigns it a
value.
(2) Preserve the notion of a binding as the association of a variable and a
value. We still say that every APPLICATION of a lambda form creates new
variables for its formal parameters. But we can now consistently say that a
variable is bound, meaning that it has a binding, meaning that it is
currently associated with a value. Leave ``boundp'' as is. Parameter
variables, special variables and global variables can all be ``bound'' to
values.
(3) Introduce some more terminology. First, state that all variables have
``bindings'', i. e., instances of variables. This includes a global binding
for the global variable named by each symbol. Different applications of a
lambda refer to different bindings of the same variable (if you must). All
variables are always ``bound'', unless perhaps you introduce some new
construct that really and abnormally removes bindings. In addition,
bindings, and only bindings, which are the only repositories for values, can
be ``assigned'' values. ``assignedp'' does what ``boundp'' now does.
Note that if you define ``binding'' as a variable instance, i. e., an
object, rather than as an association of a variable (or variable instance)
with a symbol (or with a value!), then we are in need of terms to describe
(1) the relation of a symbol to a variable, (2) the relation of a variable
to its binding(s), and (3) relation of a binding to a value. The first
seems to be the ``naming'' or ``named by'' relation; the second may be
called ``instantiation'', or some such, and the third could be called
``assignment.''
Personally, I prefer (1). It is simplest and least confusing. The
terminology of shadowing can still apply to give a lucid description of the
rules of reference. Also, it seems to be most compatible with the notion of
generalized variables.
(2) Special Form Terminology
A special form is defined as a form beginning with one of the symbols
appearing in Table 5-1. However, p. 57 states that ``The set of special
forms is fixed in Common LISP'' and that ``The set of special forms in
Common LISP is purposely kept very small''. Of course, these claims are
both false. There are an infinite number of special forms in Common LISP.
What is finite and small is the set of symbols that designate special forms.
These are referred to in Table 5-1 as the ``names'' of special forms.
Ugh. I propose the following terminology: Leave the definition of special
forms alone. Call the objects referred to by the symbols that designate
special forms ``special functions''. Call the objects referred to by
symbols that invoke macro definitions ``macro functions''. Call everything
else a ``normal'' function. These are the unmarked case, analogous to the
lack of a compelling name for non-``special'' variables.
This terminology appears to be consistent with ``symbol-function'', which
may return something ``representing a special form (sic) or macro.''
∂07-Jun-85 0651 gls@THINK.ARPA Arrays with zero dimensions.
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 7 Jun 85 06:50:52 PDT
Received: by THINK.ARPA with CHAOS id AA05194; Fri, 7 Jun 85 09:47:08 edt
Date: Friday, 7 June 1985, 09:48-EDT
From: Guy Steele <gls@THINK.ARPA>
Subject: Arrays with zero dimensions.
To: greek@DEC-HUDSON@THINK.ARPA, common-lisp@su-ai
Cc: gls@THINK.ARPA
In-Reply-To: The message of 6 Jun 85 15:30-EDT from greek at DEC-HUDSON at think
Message-Id: <850607094803.1.GLS@DESIDERIUS.ARPA>
Date: Thu, 06 Jun 85 15:30:40 EDT
From: greek@DEC-HUDSON@think
Is it really of cosmic importance that we allow dimensions of zero?
We sure could invent a lot of baggage to handle it correctly, but...
- Paul
Well, empty strings have their uses. And in image processing I can
easily imagine wanting to extract a sub-rectangle of a rectangular
pixel array; in certain boundary cases one dimensions might be zero.
--Guy
∂07-Jun-85 0933 greek@DEC-HUDSON Arrays with Zero Dimensions
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 7 Jun 85 09:33:24 PDT
Date: Fri, 07 Jun 85 12:33:33 EDT
From: greek@DEC-HUDSON
Subject: Arrays with Zero Dimensions
To: common-lisp@su-ai
Yes, I should have made myself clearer. Of course, zero-length vectors
are great. But once you go to multiple dimensions, the problem of
telling which is zero is messy.
- Paul
∂09-Jun-85 1707 DCP@SCRC-YUKON.ARPA Arrays with zero dimensions.
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 9 Jun 85 17:06:51 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 130299; Sun 9-Jun-85 13:43:55-EDT
Date: Sun, 9 Jun 85 14:56 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Arrays with zero dimensions.
To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 6 Jun 85 15:30-EDT from greek@DEC-HUDSON
Message-ID: <850609145609.5.NFEP@NEPONSET.SCRC.Symbolics.COM>
Date: Thu, 06 Jun 85 15:30:40 EDT
From: greek@DEC-HUDSON
Is it really of cosmic importance that we allow dimensions of zero?
We sure could invent a lot of baggage to handle it correctly, but...
We already have it:
(array-dimensions "") => (0)
The problems presented so far only come up when the number of dimensions
is 2 or more. My answer to that is that such arrays have legitimate
structure and are therefore meaningful. Zero-dimensional arrays
likewise have legitimate structure, which is why I assume they were
included in the language.
∂09-Jun-85 1707 DCP@SCRC-YUKON.ARPA common lisp- &environment objects
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 9 Jun 85 17:07:10 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 130300; Sun 9-Jun-85 13:48:51-EDT
Date: Sun, 9 Jun 85 15:01 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: common lisp- &environment objects
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>,
Guy Steele <gls@THINK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12116842945.BABYL@CMU-CS-C.ARPA>
Message-ID: <850609150107.6.NFEP@NEPONSET.SCRC.Symbolics.COM>
Date: Wed, 5 Jun 1985 22:06 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
The book is silent in the question of the extent of environments as delivered
to &environment bindings in DEFMACRO, hook functions, etc. What shall we say?
One false move here and we have not Lisp but Conniver. How about
requiring "dynamic" extent for environment objects, and no more? Will
that take care of the needs for macro-expansion, steppers, and so on?
True, you could imagine cute ways of using environments that outlive
their invocations, but I REALLY don't want to pay for those cute uses
with inefficiency or severe constraints on the implementor. If anyone
wants to implement Conniver in Common Lisp, I can supply the old Maclisp
code, but let's not drag down Common Lisp itself.
Moon very carefully solved this problem in Symbolics' implementation of
Common Lisp by having an &ENVIRONMENT keyword to defmacro and making
sure all possible expanders of macros took an optional environment
argument, to which they can pass to MACROEXPAND(-1). This isn't cute;
it is functional. It isn't inefficient and it doesn't pose any
constraints on the implementor, unless I misunderstand what "the
implementor" is suposed to mean.
∂09-Jun-85 1756 ima!inmet!norman@cca-unix
Received: from CCA-UNIX.ARPA by SU-AI.ARPA with TCP; 9 Jun 85 17:56:22 PDT
Received: by cca-unix.ARPA (4.12/4.7)
id AA29292; Sun, 9 Jun 85 20:55:25 edt
Date: Sun, 9 Jun 85 20:55:25 edt
From: ima!inmet!norman@cca-unix
Message-Id: <8506100055.AA29292@cca-unix.ARPA>
Sender: inmet!norman@cca-unix
To: Common-lisp@SU-AI.ARPA
Would you add my name to the common lisp distributaion list.
My mailing address is ima!imnet!norman@cca-unix.arpa
Thanks Norman rubin
Intermetrics
∂09-Jun-85 2016 FAHLMAN@CMU-CS-C.ARPA common lisp- &environment objects
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 Jun 85 20:16:07 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 9 Jun 85 23:17:03-EDT
Date: Sun, 9 Jun 1985 23:17 EDT
Message-ID: <FAHLMAN.12117904408.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David C. Plummer in disguise" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: common lisp- &environment objects
In-reply-to: Msg of 9 Jun 1985 15:01-EDT from David C. Plummer in disguise <DCP at SCRC-QUABBIN.ARPA>
One false move here and we have not Lisp but Conniver. How about
requiring "dynamic" extent for environment objects, and no more? Will
that take care of the needs for macro-expansion, steppers, and so on?
True, you could imagine cute ways of using environments that outlive
their invocations, but I REALLY don't want to pay for those cute uses
with inefficiency or severe constraints on the implementor. If anyone
wants to implement Conniver in Common Lisp, I can supply the old Maclisp
code, but let's not drag down Common Lisp itself.
Moon very carefully solved this problem in Symbolics' implementation of
Common Lisp by having an &ENVIRONMENT keyword to defmacro and making
sure all possible expanders of macros took an optional environment
argument, to which they can pass to MACROEXPAND(-1). This isn't cute;
it is functional. It isn't inefficient and it doesn't pose any
constraints on the implementor, unless I misunderstand what "the
implementor" is suposed to mean.
I don't understand what you are saying here. What does this have to do
with the extent of environment objects? What, exactly, are you arguing
for?
As I said in an immediate follow-up to the above message, you only get a
lot of additional expense if you actually let users do all of the
"obvious" things with an immortal environment object, such as going to
the tags and diddling the lexical variables. I really don't care if
environment objects have indefinite or dynamic extent, as long as these
expensive kinds of uses are clearly forbidden once you exit the dynamic
extent, but the politics of this group are such that we must be very
careful about introducing features that, if taken to their logical
conclusion, lead us to somewhere we don't want to go; there are always a
lot of people who demand that everything be taken to its logical
conclusion, and damn the expense, so it is sometimes better not to take
the first step.
I do note that the original query suggested that Symbolics was
stack-allocating environment objects, and other implementations might
want to do similarly tense things in order to make the interpreter
reasonably cons-free. That suggests to me that it would be a good idea
to allow environment objects to have dynamic extent only, unless someone
can explain why this is unworkable or can demonstrate some important
thing that cannot be done if we take this position. I am always
nervous about disappearing objects, such as the disappearing &rest args
in Zetalisp (not legal in Common Lisp), but in the case of environment
arguments we might choose to go with a dangerous but efficient solution.
-- Scott
∂10-Jun-85 0357 DCP@SCRC-STONY-BROOK.ARPA common lisp- &environment objects
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Jun 85 03:57:02 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 250864; Mon 10-Jun-85 06:54:31-EDT
Date: Mon, 10 Jun 85 06:56 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: common lisp- &environment objects
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>,
David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12117904408.BABYL@CMU-CS-C.ARPA>
Message-ID: <850610065628.8.NFEP@NEPONSET.SCRC.Symbolics.COM>
Date: Sun, 9 Jun 1985 23:17 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
One false move here and we have not Lisp but Conniver. How about
requiring "dynamic" extent for environment objects, and no more? Will
that take care of the needs for macro-expansion, steppers, and so on?
True, you could imagine cute ways of using environments that outlive
their invocations, but I REALLY don't want to pay for those cute uses
with inefficiency or severe constraints on the implementor. If anyone
wants to implement Conniver in Common Lisp, I can supply the old Maclisp
code, but let's not drag down Common Lisp itself.
Moon very carefully solved this problem in Symbolics' implementation of
Common Lisp by having an &ENVIRONMENT keyword to defmacro and making
sure all possible expanders of macros took an optional environment
argument, to which they can pass to MACROEXPAND(-1). This isn't cute;
it is functional. It isn't inefficient and it doesn't pose any
constraints on the implementor, unless I misunderstand what "the
implementor" is suposed to mean.
I don't understand what you are saying here. What does this have to do
with the extent of environment objects? What, exactly, are you arguing
for?
I'm arguing that CLtL says much too little about environments. It does
not say how to get your hands on one, but specifies them as optional
arguments to functions, for example EVALHOOK, APPLYHOOK, MACROEXPAND(-1)
(and in our implementation EVAL). Dynamic extent isn't good enough; how
can you do upward funargs? This is far from cute:
(defun adder (val)
#'(lambda (x) (+ x val)))
it is instead at the heart of lexical scoping.
As I said in an immediate follow-up to the above message, you only get a
lot of additional expense if you actually let users do all of the
"obvious" things with an immortal environment object, such as going to
the tags
Tags have dynamic extent. Going with tags outside their dynamic extent
should generate errors.
and diddling the lexical variables.
What good is lexical scoping if you can't diddle lexical variables?
I really don't care if
environment objects have indefinite or dynamic extent, as long as these
expensive kinds of uses are clearly forbidden once you exit the dynamic
extent, but the politics of this group are such that we must be very
careful about introducing features that, if taken to their logical
conclusion, lead us to somewhere we don't want to go; there are always a
lot of people who demand that everything be taken to its logical
conclusion, and damn the expense, so it is sometimes better not to take
the first step.
CLtL'84, on page 39 pretty clearly gives the scope and extent of just
about everything. Maybe you are concerned that I want the users to
diddle with the environment itself? Not at all. The structure of the
environment is peculiar to the implementation. I am, perhaps
incorrectly, assuming that creating a lexical closure captures the
current environment.
I do note that the original query suggested that Symbolics was
stack-allocating environment objects, and other implementations might
want to do similarly tense things in order to make the interpreter
reasonably cons-free. That suggests to me that it would be a good idea
to allow environment objects to have dynamic extent only, unless someone
can explain why this is unworkable or can demonstrate some important
thing that cannot be done if we take this position. I am always
nervous about disappearing objects, such as the disappearing &rest args
in Zetalisp (not legal in Common Lisp), but in the case of environment
arguments we might choose to go with a dangerous but efficient solution.
I'll repeat the classic lexical scoping example:
(defun adder (val)
#'(lambda (x) (+ x val)))
Environments must have indefinite extent (at least the environment of
non-special variables and local functions (FLET, LABELS)). The way this
works is that the environment has a slot which is called ENV-EVACUATION
which is the heap version created as necessary. Therefore, internal
interpreter functions (e.g., the definition of the FUNCTION special
form) explicitly evacuate the environment since it is being stored in
permanent storage.
∂10-Jun-85 0646 FAHLMAN@CMU-CS-C.ARPA common lisp- &environment objects
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Jun 85 06:46:12 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 10 Jun 85 09:47:18-EDT
Date: Mon, 10 Jun 1985 09:47 EDT
Message-ID: <FAHLMAN.12118019135.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David C. Plummer in disguise" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: common lisp- &environment objects
In-reply-to: Msg of 10 Jun 1985 06:56-EDT from David C. Plummer in disguise <DCP at SCRC-QUABBIN.ARPA>
I'm arguing that CLtL says much too little about environments. It does
not say how to get your hands on one, but specifies them as optional
arguments to functions, for example EVALHOOK, APPLYHOOK, MACROEXPAND(-1)
(and in our implementation EVAL). Dynamic extent isn't good enough; how
can you do upward funargs? This is far from cute:
(defun adder (val)
#'(lambda (x) (+ x val)))
it is instead at the heart of lexical scoping.
Ah, OK, we've got some misunderstanding here between the general concept
of an environment and the specific concept of an environment object, as
returned by &environment. I agree that lexical closures have to work,
and that this requires that some parts of the environment in which a
function is closed be saved with indefinite extent. However, this
doesn't say that environment objects must have indefinite extent. It
doesn't even say that the lexical variable part of the environment has
to be saved or has to be an object with indefinite extent. In our
current (inefficient) Spice Lisp interpreter, this environment is a
consed A-list, but one could certainly imagine an implementation that
stack allocated this structure (with provision for saving it if a
closure is created) or some sort of shallow-bound variable environment
that never has a specific object that represents the current variable
environment, but that somehow arranges to save all the right value cells
when a closure is created. So I agree that closures have to work, but
not that this implies anything about the extent of environment objects.
In speaking of the expense of diddling variable values, I am referring
to those values that are not part of any lexical closure, but that might
somehow still be accessible if we were to take seriously the notion that
environment objects can be kept alive indefinitely and passed around. I
don't think we want to allow this. We do, of course, have to make sure
that properly created lexical closures work properly, but we should not
specify the internal mechanism that makes that possible. Parts of the
lexical function name environment must similarly be of indefinite extent
if FLET and LABELS are to work properly, but again we do not need to
keep the entire environment around in order to accomplish this.
Clearly go-tags and block-names want to become inoperative outside of
the dynamic extent of their blocks, whatever we decide about the extent
of environment objects.
So again the question is whether we can accomplish everything we need to
with environment objects even if these objects have only dynamic extent.
Whether some parts of the environment need to have indefinite extent in
order to make closures work is a different question, I think.
-- Scott
∂10-Jun-85 0702 REM@IMSSS Environment-objects don't exist in CL according to manual
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Jun-10 06:01:26 PST (=GMT-8hr)
Date: 1985 June 10 06:00:54 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132222142466.G0353
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:COMMON-LISP@SU-AI
SUBJECT:Environment-objects don't exist in CL according to manual
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up)
Prodded by all this recent discussion about whether environments have
dynamic or indefinite extent, how one might obtain an
environment-object so as to pass it as optional argument to EVAL, what
kinds of info might be captured in such an object, I looked in the
index to the CL manual to see what the manual said about environments.
The answer, if I can believe the index, is that CL has no such things
as environment objects. There are only two mentions of "environment"
in the index: one referring to a general statement that special
structures in CL allow the programmer to organize a program, some
having to do with flow of control (control structures) and others
controlling access to variables (environment structures); the other
referring to LISP funcitons to query the system regarding such matters
as time-of-day or CPU-ID. Neither has anything to do with the topic
that seems to be under discussion recently.
Is this recent discussion utter nonsense (referring to some local
extension to CL rather than to CL itself), or is the index grossly
deficient in this topic? If the latter, can somebody supply me/us with
a list of pages where environment objects are discussed in the CL
manual? If the former, there seems to be no need to introduce the
topic; if environment-objects can't be passed to functions, there's no
need to worry about how to create them or what aspects of the
environment they might encapsulate if they could be created.
∂10-Jun-85 0748 FAHLMAN@CMU-CS-C.ARPA Environment-objects don't exist in CL according to manual
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Jun 85 07:48:35 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 10 Jun 85 10:49:50-EDT
Date: Mon, 10 Jun 1985 10:49 EDT
Message-ID: <FAHLMAN.12118030498.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: REM%IMSSS@λSU-SCORE.ARPA (temporary until nameservers up)λ
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Environment-objects don't exist in CL according to manual
Assuming that something doesn't exist in Common Lisp just because it
doesn't appear in the index of the manual is a pretty risky business.
In fact, this business of environment objects would probably be indexed
under &environment, but all the &-thingies got left out of the index.
In this case, the problem is compounded by a serious typo in the text.
The use of &evironment in the arglist of a defmacro is described on page
145 at the very bottom. In my copy of the manual, at least, the actual
word "&environment" got left out, but it is supposed to be the label for
the last paragraph on this page, after the paragraph describing &whole.
Uses of these environment objects are described under macroexpand and
macroexpand-1, and also under the hook functions in the Eval chapter.
Subsequent discussion has revealed that you also need these environment
objects as arguments to the proposed PARSE-BODY, to MACRO-FUNCTION, and
also to GET-SETF-METHOD. Arguably also to EVAL, because of the damned
macro-> declaration business, but I'm not sure about that. Basically,
everyone who might have to expand a macro as part of the expansion of
another macro has to receive the environment object so that lexically
defined macros are handled properly.
I have come around to the conclusion that we really blew it when we let
MACROLET into the language, despite that operator's occasional
usefulness. If not for that, none of this environment hackery would be
necessary, and macro->declaration processing would be straightforward.
-- Scott
∂10-Jun-85 1040 HEDRICK@RUTGERS.ARPA extent of environments
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 10 Jun 85 10:40:06 PDT
Date: 10 Jun 85 13:39:50 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: extent of environments
To: common-lisp@SU-AI.ARPA
TOPS-20 Common Lisp in fact does precisely what Scott conjectured
a hypothetical implementation might do: We put the environment
information on the stack. We copy it into the heap whenever we have
to give the information to the user. This seems to speed up the
interpreter a lot. If somebody can guarantee us that the things
we give to a macro with &environment can safely be left on the
stack, that would speed up those macro expansions. This is not
critical, however, since we only do macro expansions once. (We
use the old UCI Lisp displacement technique.) What has actually
stopped us from doing &environment is not this problem (which is
trivial to fix - after all we already have the function to copy
the environment into the heap) but the fact that we have to make
the compiler do it also. Thus the compiler is going to have to
construct an environment which will look to the macro as if it were
the runtime enviornment in which the macro was called. The copy
of Spice Lisp that we have (which may, as usual, be slightly
out of date) simply doesn't deal with these issues. Indeed in
SETF they have a separate macro expander that explicitly tests
whether it is in the compiler or not. We are going to have to
replace that with a new mechanism that does things right. The
whole implementation of macros that expand to declarations and
&environment seems to be one single knotted mess, which I will
solve the first time I get a weekend that I can devote to it.
-------
∂10-Jun-85 1108 greek@DEC-HUDSON Scott's observation on MACROLET
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 10 Jun 85 11:07:54 PDT
Date: Mon, 10 Jun 85 13:37:28 EDT
From: greek@DEC-HUDSON
Subject: Scott's observation on MACROLET
To: common-lisp@su-ai
MACROLET? What's MACROLET? Must be a mistake. Let's erase it from
the book.
- Paul
∂10-Jun-85 1200 DCP@SCRC-STONY-BROOK.ARPA common lisp- &environment objects
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Jun 85 11:59:44 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 251236; Mon 10-Jun-85 14:57:03-EDT
Date: Mon, 10 Jun 85 14:59 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: common lisp- &environment objects
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>,
David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12118019135.BABYL@CMU-CS-C.ARPA>
Message-ID: <850610145904.7.NFEP@NEPONSET.SCRC.Symbolics.COM>
Date: Mon, 10 Jun 1985 09:47 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
So again the question is whether we can accomplish everything we need to
with environment objects even if these objects have only dynamic extent.
Whether some parts of the environment need to have indefinite extent in
order to make closures work is a different question, I think.
OK, I think I understand the question you are asking. My question is:
Does it matter? I cannot think of any valid programs (read: macros)
that would want to store an environment in permanent storage. For that
matter, I cannot think of any valid programs (read: macros) that side
effect the environment. They only USE them, which means you pass them
as arguments to macroexpand(-1). Therefore, I don't think it matters
how they are implemented, since all programs should be using them as
lexical scope, dynamic extent, which is the most restrictive. The only
"program" that needs to update the environment is the interpreter (read:
special forms), and that "program" is supplied by the vendor and users
don't need to know about it.
Aside: Symbolics' EVAL function takes an &OPTIONAL ENV argument so that
the implementation of special forms can call EVAL instead of
EVAL-WITH-ENV or somesuch.
∂10-Jun-85 2256 @MIT-MC:BROOKS@MIT-OZ function type specifiers
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Jun 85 22:56:10 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 11 JUN 85 01:00:22 EDT
Date: Tue 11 Jun 85 00:57:48-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: function type specifiers
To: common-lisp@SU-AI.ARPA
cc: jk@SU-AI.ARPA
In CTtL page 47 it defines a function type specifier to look like:
(function (arg1-type arg2-type ...) value-type)
and says "The value-type may be a values type specifier in order to
indicate the types of multiple values.".
On page 158 in talking about delarations it says that for
(ftype type function-name-1 function-name-2 ...)
type must be a functional type. Then on page 159 it says that
(function name arglist result-type1 result-type-2 ...)
is entirely equivalent to
(ftype (function arglist result-type1 result-type2 ...) name)
which establishes a contradiction. Page 159 should be changed.
-------
∂11-Jun-85 1043 RWW using lower case
To: common-lisp@SU-AI.ARPA
Is there any way to make common lisp simply be totally case sensitive in the
naive way? I would somply like symbols to have PNAMES like
Hello or
hEllo or
heLLo
...
and all be different symbols which I do not need to type any other
characters to use this way?
Richard
∂11-Jun-85 1245 Moon@SCRC-STONY-BROOK.ARPA Adjustable and displaced arrays
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 12:45:10 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252220; Tue 11-Jun-85 15:42:22-EDT
Date: Tue, 11 Jun 85 15:44 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Adjustable and displaced arrays
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>, greek@DEC-HUDSON.ARPA,
Glenn S. Burke <GSB@MIT-MC.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12113193061.BABYL@CMU-CS-C.ARPA>,
The message of 23 May 85 09:57-EDT from greek@DEC-HUDSON,
<850523163729.9.NFEP@NEPONSET.SCRC.Symbolics.COM>,
<[MIT-MC].516737.850524.GSB0>,
The message of 28 May 85 11:21-EDT from greek@DEC-HUDSON,
<850528124820.3.NFEP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <850611154451.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Perhaps I can clarify one or two points in this discussion.
Date: Wed, 22 May 1985 23:56 EDT
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
I am somewhat confused about the interaction between array adjustment
and displacement.
In CLTL p298:
Note that if the array a is created displaced to array b and
subsequently array b is given to adjust-array, array a will still
be displaced to array b; the effects of this displacement and the
rule of row-major storage order must be taken into account.
What is this trying to say? Is this a warning to the user or a threat
to the implementor? The obvious interpretation of this statement
seems to require that all non-simple arrays contain a list of all the
other array headers that share the same data so that they can be fixed
up when the array is adjusted. The answer that you stick in a
forwarding pointer is not acceptable.
I can't tell what you mean by your last two sentences, but if you encache
information about array b inside of array a, you must arrange one way or
another to discover when that cache is invalid. An alternative to encaching
is to examine array b on every access to array a. We use a combination of
both techniques; normal array accesses to array a examine array b, but a
tight array processing loop can use a declaration to get the array decoding
moved outside of the loop. This encached information is automatically
updated if any array is adjusted (our hardware can do with this without
taking any extra time; the validity check for the encached information
consists of comparing two numbers, one of which increments every time an
array is adjusted, and is overlapped with memory access time). In a system
that doesn't allow multiple processes, you could probably get away without
any provision for cache updating if you require the user not to do any
array adjustment inside his inner loop.
The statement in the manual also doesn't answer the question of what
happens to array b if array a is adjusted. Is it legal or meaningful
to have arrays which are both displaced to another array and
adjustable? What are the semantics of adjusting such an array?
The answer is that it is extremely straightforward. Adjusting array a
never affects array b in any way. Adjusting a displaced array never moves
any data elements around in storage; it simply changes the dimensions,
displaced-to, and/or index-offset of the displaced array. It sounds like
the manual needs to be improved.
Date: Thu, 23 May 85 09:57:23 EDT
From: greek@DEC-HUDSON
We were so confused about the problem of adjusting displaced arrays,
we simply don't allow it in VAX LISP. I'd sure appreciate some
thoughts on the matter myself.
See above; adjusting displaced arrays is much easier than adjusting
ordinary arrays.
Date: Tue, 28 May 85 11:21:20 EDT
From: greek@DEC-HUDSON
Erf! I certainly should have objected to the incredible hair needed
to implement adjustable arrays, particularly those which are displaced,
back when we specified them. However, I'd like to object now.
I'd like to see a list of the uses people make of displaced and
adjustable arrays. Maybe there are only two or three real features
that people use, and we could restrict ourselves to those. I looked
around here at DEC, and found exactly two uses:
1. Make an array bigger. Obviously this could be done with MAKE-ARRAY
and REPLACE.
This is not obvious at all! Suppose there are multiple references to the
original array; how do they get updated to refer to the new copy? That
issue is the whole reason why adjustable arrays exist.
2. Linearize a multidimensional array so that row-major references
can be done. This is useful, but an AREF-ROW-MAJOR function could
probably do it more efficiently.
It seems to me that any set of rules that require AREF to iterate to
find the data ought to be simplified. So much for inline code.
Common Lisp was explicitly not designed for efficient implementation on
Fortran machines in the absence of declarations. Does the ability to declare
an array to be SIMPLE take care of your problems with implementing inline
code for AREF? If not, there is an issue we need to address.
Date: Tue, 28 May 85 12:48 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
I don't think we don't use it for your case (1); instead we do make a
new array, copy, and structure forwared the old to the new. They can
also be used for your case (2), but I think the our function
SYS:%1D-AREF subsumes the need.
Slight clarifications: SYS:%1D-AREF and AREF-ROW-MAJOR are two names for
exactly the same thing. "structure forward" is a Lisp machine concept
that does not exist in Common Lisp.
∂11-Jun-85 1247 FAHLMAN@CMU-CS-C.ARPA using lower case
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 12:47:48 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 11 Jun 85 15:46:08-EDT
Date: Tue, 11 Jun 1985 15:46 EDT
Message-ID: <FAHLMAN.12118346592.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Richard Weyhrauch <RWW@SU-AI.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: using lower case
In-reply-to: Msg of 11 Jun 1985 13:43-EDT from Richard Weyhrauch <RWW at SU-AI.ARPA>
There is no way in standard Common Lisp to get full case-sensitivity as
the reader default. Individual implementations may have a
case-sensitive input mode as an extension, but the CMU code upon which
many Common Lisp implementations are based does not have this feature.
-- Scott
∂11-Jun-85 1259 Moon@SCRC-STONY-BROOK.ARPA Degenerate array axes
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 12:59:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252237; Tue 11-Jun-85 15:54:53-EDT
Date: Tue, 11 Jun 85 15:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Degenerate array axes
To: Jon White <JLW@SU-AI.ARPA>, Guy Steele <gls@THINK.ARPA>,
Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>,
Richard Mlynarik <MLY@MIT-MC.ARPA>, greek@DEC-HUDSON.ARPA,
David C. Plummer in disguise <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 6 Jun 85 08:43-EDT from Jon White <JLW@SU-AI.ARPA>,
<850606103442.4.GLS@DESIDERIUS.ARPA>,
<FAHLMAN.12116985877.BABYL@CMU-CS-C.ARPA>,
<[MIT-MC.ARPA].532788.850606.MLY>,
The message of 6 Jun 85 15:30-EDT from greek@DEC-HUDSON,
The message of 7 Jun 85 12:33-EDT from greek@DEC-HUDSON,
<850609145609.5.NFEP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <850611155723.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I read the seven messages in this discussion about multidimensional arrays where
some of the dimensions (other than the last) are zero. My opinion is that the
language semantics are correct and consistent, and the problem lies solely in
the print syntax. The best suggestion so far, in my opinion, is the one from
Mlynarik that when array cannot be meaningfully be printed with #A it should
be printed with #.(MAKE-ARRAY ...).
∂11-Jun-85 1311 Moon@SCRC-STONY-BROOK.ARPA common lisp- &environment objects
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 13:11:16 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252256; Tue 11-Jun-85 16:08:31-EDT
Date: Tue, 11 Jun 85 16:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: common lisp- &environment objects
To: David C. Plummer in disguise <DCP@QUABBIN.SCRC.Symbolics.COM>,
Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850610145904.7.NFEP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <850611161100.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 10 Jun 85 14:59 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Date: Mon, 10 Jun 1985 09:47 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
So again the question is whether we can accomplish everything we need to
with environment objects even if these objects have only dynamic extent.
Whether some parts of the environment need to have indefinite extent in
order to make closures work is a different question, I think.
OK, I think I understand the question you are asking. My question is:
Does it matter? I cannot think of any valid programs (read: macros)
that would want to store an environment in permanent storage. For that
matter, I cannot think of any valid programs (read: macros) that side
effect the environment. They only USE them, which means you pass them
as arguments to macroexpand(-1). Therefore, I don't think it matters
how they are implemented, since all programs should be using them as
lexical scope, dynamic extent, which is the most restrictive. The only
"program" that needs to update the environment is the interpreter (read:
special forms), and that "program" is supplied by the vendor and users
don't need to know about it.
I think Scott has hit the nail on the head and I also agree with Dave's comments.
To sum up: the data structure that Common Lisp offers to users is the lexical
closure, not the environment. The only thing a user can do with an environment
is receive it as an argument and pass it to another function as an argument.
I believe that these environments should be defined to have only dynamic extent;
in other words, a user isn't allowed to save them away in permanent structures.
∂11-Jun-85 1316 Moon@SCRC-STONY-BROOK.ARPA Does Defmacro establish a block?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 13:16:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252265; Tue 11-Jun-85 16:12:17-EDT
Date: Tue, 11 Jun 85 16:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Does Defmacro establish a block?
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA, bug-CLCP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <RAM.12114291388.BABYL@CMU-CS-C.ARPA>
Message-ID: <850611161450.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 27 May 1985 04:30 EDT
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Does defmacro establish a named block around the definition the
same way that defun does? CLTL doesn't mention this issue at all,
leading one to suppose that it doesn't, but this seems to create a
pointless inconsistency with defun.
If defmacro does, do define-setf-method, defsetf, deftype...?
I believe that all defining forms that have a name and a body should put
a named block around the body. In our implementation, defun and defmacro
do so, but currently the others you mentioned do not. I'm calling that
a bug in our implementation and suggesting that a future clarification
of Common Lisp should require this.
∂11-Jun-85 1317 gls@THINK.ARPA Environment-objects don't exist in CL according to manual
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 13:17:29 PDT
Received: by THINK.ARPA with CHAOS id AA27754; Tue, 11 Jun 85 16:12:51 edt
Date: Tuesday, 11 June 1985, 16:14-EDT
From: Guy Steele <gls@THINK.ARPA>
Subject: Environment-objects don't exist in CL according to manual
To: REM%IMSSS@SU-SCORE.ARPA, COMMON-LISP@SU-AI
Cc: gls@THINK.ARPA
In-Reply-To: SU-IMSSS.REM.A132222142466.G0353
Message-Id: <850611161408.2.GLS@ROCK.ARPA>
Date: 1985 June 10 06:00:54 PST (=GMT-8hr)
From: Robert Elton Maas <REM@IMSSS.SU.EDU@think>
...
The answer, if I can believe the index, is that CL has no such things
as environment objects. ...
You can't believe the index. The index is lousy. I am looking into automated
technology to improve the index for the next edition.
--Guy
∂11-Jun-85 1817 FAHLMAN@CMU-CS-C.ARPA Does Defmacro establish a block?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 18:16:51 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 11 Jun 85 21:17:43-EDT
Date: Tue, 11 Jun 1985 21:17 EDT
Message-ID: <FAHLMAN.12118406963.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA, Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Subject: Does Defmacro establish a block?
In-reply-to: Msg of 11 Jun 1985 16:14-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
If defmacro does, do define-setf-method, defsetf, deftype...?
I believe that all defining forms that have a name and a body should put
a named block around the body. In our implementation, defun and defmacro
do so, but currently the others you mentioned do not. I'm calling that
a bug in our implementation and suggesting that a future clarification
of Common Lisp should require this.
I can accept this, but let's be sure we agree on what the block name
would be in each case. For the SETF forms, is it the name of the
accessing operator? For DEFTYPE, is it the name of the type?
-- Scott
∂11-Jun-85 1819 FAHLMAN@CMU-CS-C.ARPA common lisp- &environment objects
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 18:19:03 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 11 Jun 85 21:20:04-EDT
Date: Tue, 11 Jun 1985 21:19 EDT
Message-ID: <FAHLMAN.12118407391.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: common lisp- &environment objects
In-reply-to: Msg of 11 Jun 1985 16:11-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
To sum up: the data structure that Common Lisp offers to users is the lexical
closure, not the environment. The only thing a user can do with an environment
is receive it as an argument and pass it to another function as an argument.
I believe that these environments should be defined to have only dynamic extent;
in other words, a user isn't allowed to save them away in permanent structures.
Fine, I agree with Moon. Any passionately dissenting opinions?
-- Scott
∂11-Jun-85 1825 FAHLMAN@CMU-CS-C.ARPA Degenerate array axes
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 18:25:38 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 11 Jun 85 21:26:34-EDT
Date: Tue, 11 Jun 1985 21:26 EDT
Message-ID: <FAHLMAN.12118408573.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Degenerate array axes
In-reply-to: Msg of 11 Jun 1985 15:57-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
OK, maybe the best way out is to follow Mlynarik's suggestion that (a)
we allow multi-D arrays with one or more dimensions of 0 and (b) we go
with #.make-array for those situations where the #A syntax can't make
it. That way we avoid a significant incompatible change to the syntax
and we avoid outlawing a heretofore legal object type.
-- Scott
∂11-Jun-85 1842 FAHLMAN@CMU-CS-C.ARPA Adjustable and displaced arrays
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 18:42:42 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 11 Jun 85 21:43:42-EDT
Date: Tue, 11 Jun 1985 21:43 EDT
Message-ID: <FAHLMAN.12118411695.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Adjustable and displaced arrays
In-reply-to: Msg of 11 Jun 1985 15:44-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
OK, if we accept Moon's view of the proper semantics for all this, and
if we decide not to outlaw displacing to adjustable arrays, then the
Fortran machines probably have to forego cacheing and let each call to
Aref potentially grovel the headers of both arrays (or a whole chain of
arrays). Maybe that is not so bad, since none of this affects
Simple-Vectors, and they are the only kind of array that really HAS to
be fast.
However, the vendors of non-microcodable machines may feel, with some
justification, that they don't want to slow down ALL references to
non-simple arrays just so that the obscure case of adjusting an array
that is displaced to will work properly. Perhaps the right move is to
unbundle the SIMPLE declaration and allow the user to declare that an
array is NOT-DISPLACED, even if it is not simple in other respects.
-- Scott
∂11-Jun-85 2048 Moon@SCRC-STONY-BROOK.ARPA Does Defmacro establish a block?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 20:48:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252531; Tue 11-Jun-85 23:45:14-EDT
Date: Tue, 11 Jun 85 23:47 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Does Defmacro establish a block?
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA, Rob MacLachlan <RAM@CMU-CS-C.ARPA>
In-Reply-To: <FAHLMAN.12118406963.BABYL@CMU-CS-C.ARPA>
Message-ID: <850611234750.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 11 Jun 1985 21:17 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
If defmacro does, do define-setf-method, defsetf, deftype...?
I believe that all defining forms that have a name and a body should put
a named block around the body. In our implementation, defun and defmacro
do so, but currently the others you mentioned do not. I'm calling that
a bug in our implementation and suggesting that a future clarification
of Common Lisp should require this.
I can accept this, but let's be sure we agree on what the block name
would be in each case. For the SETF forms, is it the name of the
accessing operator? For DEFTYPE, is it the name of the type?
Yes. I propose this rule: In any DEFxxx form that has a body that is code to
executed, then if CADR of the form is a symbol, then a BLOCK with that symbol
as its name is automatically wrapped around the body in such a place that
RETURN-FROM that block is the same as making the body evaluate to the returned
value. The complicated language here is to deal with the case where the
form expands into a large bunch of code with the user-supplied body buried
somewhere inside it.
∂11-Jun-85 2052 Moon@SCRC-STONY-BROOK.ARPA Adjustable and displaced arrays
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 20:52:13 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252533; Tue 11-Jun-85 23:49:29-EDT
Date: Tue, 11 Jun 85 23:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Adjustable and displaced arrays
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12118411695.BABYL@CMU-CS-C.ARPA>
Message-ID: <850611235159.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 11 Jun 1985 21:43 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
OK, if we accept Moon's view of the proper semantics for all this, and
if we decide not to outlaw displacing to adjustable arrays, then the
Fortran machines probably have to forego cacheing and let each call to
Aref potentially grovel the headers of both arrays (or a whole chain of
arrays). Maybe that is not so bad, since none of this affects
Simple-Vectors, and they are the only kind of array that really HAS to
be fast.
However, the vendors of non-microcodable machines may feel, with some
justification, that they don't want to slow down ALL references to
non-simple arrays just so that the obscure case of adjusting an array
that is displaced to will work properly. Perhaps the right move is to
unbundle the SIMPLE declaration and allow the user to declare that an
array is NOT-DISPLACED, even if it is not simple in other respects.
Sure. I would think that an appropriate way to proceed would be for the
implementors on non-Lisp machines to get together and agree on a common
set of language extensions to deal with this sort of issue. At a later
time, those extensions can be moved into the standard language, once
they are well-debugged and agreed to be the right thing for all machines
that need them. Until that happens, programs that use the extensions won't
be portable to all implementations (but they will probably be portable to
almost all implementations if the extensions are designed right, e.g. as
ignorable declarations).
∂12-Jun-85 0417 walton%ll-xn.arpa@ll-xn.arpa Two suggestions on array adjustability.
Received: from LL-XN.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 04:16:54 PDT
Received: by ll-xn.arpa.ARPA (4.24/4.7)
id AA02250; Wed, 12 Jun 85 07:17:35 edt
Date: Wed, 12 Jun 85 07:17:35 edt
From: walton%ll-xn.arpa@ll-xn.ARPA (Robert Walton)
Message-Id: <8506121117.AA02250@ll-xn.arpa.ARPA>
To: common-lisp@su-ai
Subject: Two suggestions on array adjustability.
We (Machine Intelligence and Tactical Sensors Project of MIT Lincoln Laboratory)
have an `image understanding operating system' called SKETCH written
in FRANZ and C and running on a VAX which has a large array package
that effectively replaces the FRANZ array package for our purposes.
Based on our experience with this, I do not think we could (optimally)
use COMMON LISP arrays for an image understanding system, and here are
two suggestions, triggered by the recent discussion of displaced arrays,
that might begin to fix this.
(1) Non-adjustability should be a dynamic declarable attribute.
If an array is declared non-adjustable in a block, it should be an error
to adjust the array when the block is active. The compiler
should make use of the declaration to optimize code.
However, when an array is in no such block, it should be adjustable.
Non-adjustability of a displaced array implies non-adjustability of
the array it is displaced to.
We often adjust displaced arrays and then pass them off to C code that
treats them as non-adjustable (given a good enough COMMON LISP compiler
we might, sometime in the future, replace the C code with COMMON LISP code).
[I would guess that non-adjustability could never be the same as simplicity,
since the later may imply a different array header structure, and untagged
hardware should know about this difference at compile time if possible.]
(2) Displaced arrays should be allowed to have non-standard subscript
multipliers. Negative multipliers and 0 should be allowed.
We use this most frequently to transpose arrays and reverse left and right
or up and down. It is obviously applicable to decimating arrays,
though we have little actual experience with this.
I offer these suggestions from the user's point of view only, though they
certainly seem implementable to me (after being refined to make them
more precise).
∂12-Jun-85 0557 greek@DEC-HUDSON Using #.(MAKE-ARRAY ...
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 05:56:41 PDT
Date: Wed, 12 Jun 85 08:56:25 EDT
From: greek@DEC-HUDSON
Subject: Using #.(MAKE-ARRAY ...
To: common-lisp@su-ai
I have an uncomfortable feeling about the printer generating complex
function calls with #. as a way to print something. I'm not really
sure why it bothers me so much.
Should we also adopt the convention that arrays which can't be printed
with #A for other reasons will be printed with #. Such things as
fill pointers, adjustability, displacement, etc. can't be represented
with #A. If we do this, then the printed representation is not
suitable for the :INITIAL-CONTENTS options, since that option won't
take an array. If we don't do this, the printer is really lying about
the array.
- Paul
∂12-Jun-85 0630 greek@DEC-HUDSON Adjusting Displaced Arrays
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 06:30:17 PDT
Date: Wed, 12 Jun 85 09:29:57 EDT
From: greek@DEC-HUDSON
Subject: Adjusting Displaced Arrays
To: common-lisp@su-ai
I'll accept the hair of allowing arbitrary "nesting" of displaced arrays,
but I don't have to like it.
Unless I missed a message, I still don't understand some things.
1. CLtL says that if the :DISPLACED-TO option is specified on ADJUST-ARRAY
then none of the original contents of the array appears in the new
array. I presume, of course, that this is not the case when displacing
back to the original target array, which I have to explicitly request
according to the first paragraph on page 298.
2. Moon stated that adjusting an array never affect the target array.
Assuming my point #1 is correct, then the target array is affected
if a) it is specified in the :DISPLACED-TO option, and b) the
:INITIAL-ELEMENT option is also specified.
If I'm incorrect here, then I think that implies that the new array
has to share some element with the original target array and also
have some of its own!
The reason we chose not to implement adjustable displaced arrays in VAX
LISP was not because we have a religious objection, but because I
didn't understand what to do. I guess I'd like to see a list of all
the options to ADJUST-ARRAY and what they do to displaced arrays.
We also need to specify any interactions between the options, such
as with :DISPLACED-TO AND :INITIAL-ELEMENT above.
- Paul
∂12-Jun-85 0928 gls@THINK.ARPA Adjusting Displaced Arrays
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 09:28:21 PDT
Received: by THINK.ARPA with CHAOS id AA05340; Wed, 12 Jun 85 12:23:04 edt
Date: Wednesday, 12 June 1985, 12:24-EDT
From: Guy Steele <gls@THINK.ARPA>
Subject: Adjusting Displaced Arrays
To: greek@DEC-HUDSON@THINK.ARPA, common-lisp@su-ai
Cc: gls@THINK.ARPA
In-Reply-To: The message of 12 Jun 85 09:29-EDT from greek at DEC-HUDSON at think
Message-Id: <850612122418.1.GLS@UBALDO.ARPA>
Date: Wed, 12 Jun 85 09:29:57 EDT
From: greek@DEC-HUDSON@think
....
2. Moon stated that adjusting an array never affect the target array.
Assuming my point #1 is correct, then the target array is affected
if a) it is specified in the :DISPLACED-TO option, and b) the
:INITIAL-ELEMENT option is also specified.
If I'm incorrect here, then I think that implies that the new array
has to share some element with the original target array and also
have some of its own!
The problem here is vague language in the manual under ADJUST-ARRAY.
Under MAKE-ARRAY, it says in more than one place that :INITIAL-ELEMENT
and :DISPLACED-TO may not be used together. This restriction should
apply to ADJUST-ARRAY also. The language under ADJUST-ARRAY is misleading
in a number of respects about how :INITIAL-ELEMENT and :DISPLACED-TO are
handled.
--Guy
∂12-Jun-85 0959 BSG@SCRC-STONY-BROOK.ARPA Using #.(MAKE-ARRAY ...
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 09:59:23 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252868; Wed 12-Jun-85 12:56:10-EDT
Date: Wed, 12 Jun 85 13:00 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Using #.(MAKE-ARRAY ...
To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 12 Jun 85 08:56-EDT from greek@DEC-HUDSON
Message-ID: <850612130012.9.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Wed, 12 Jun 85 08:56:25 EDT
From: greek@DEC-HUDSON
I have an uncomfortable feeling about the printer generating complex
function calls with #. as a way to print something. I'm not really
sure why it bothers me so much.
Well, for one, if I had some complex network of displaced arrays with
all sorts of hairy attributes, I think it would be as part of
some complicated data structure: an attempt to print them out
in such away that the reader, on reading-back-in, would create
an array "similar to lisp", but in no way part of the data
structure of my program at that time, is wholly bogus and misguided help.
Should we also adopt the convention that arrays which can't be printed
with #A for other reasons will be printed with #. Such things as
fill pointers, adjustability, displacement, etc. can't be represented
with #A. If we do this, then the printed representation is not
suitable for the :INITIAL-CONTENTS options, since that option won't
take an array. If we don't do this, the printer is really lying about
the array.
By my argument above, the more cases it uses #< (I think that's what you meant)
the better it is, and the fewer times it will lie about arrays.
- Paul
∂12-Jun-85 1225 greek@DEC-HUDSON Printing Arrays with #.
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 12:25:06 PDT
Date: Wed, 12 Jun 85 15:24:48 EDT
From: greek@DEC-HUDSON
Subject: Printing Arrays with #.
To: common-lisp@su-ai
Just to clarify, I really was asking whether all funny arrays should
be printed with #. (not #<>). I don't like the idea, either for
arrays with zero dimensions or for nonsimple arrays, but I'm not
sure why it bothers me. I'd rather see those guys printed with #<>.
- Paul
∂12-Jun-85 1312 REM@IMSSS Test suite to say what manual is confusing about
Received: from IMSSS by SU-AI with PUP; 12-Jun-85 13:12 PDT
Date: 12 Jun 1985 1310-PDT
From: Rem@IMSSS
Subject: Test suite to say what manual is confusing about
To: COMMON-LISP@SU-AI
It seems to me urgent to create a test suite for aspects of CL that are
so complicated that nobody has found a way to explain them so that a
majority of readers would truly understand them. Thus the test suite would
determine whether a given implementation is correct or not, and would serve
as the standard definition until such time as somebody figures out how
to explain it precisely in English.
It also seems that displaced adjustable mumble arrays is a case where
this need for test suite applies. Anybody who thinks he understands what
the manual meant to say, care to volunteer to make a test suite for arrays?
(Anybody agree with my opinion that test suite is needed for such?)
-------
∂12-Jun-85 1339 REM@IMSSS Printing of displaced/shared arrays
Received: from IMSSS by SU-AI with PUP; 12-Jun-85 13:37 PDT
Date: 12 Jun 1985 1334-PDT
From: Rem@IMSSS
Subject: Printing of displaced/shared arrays
To: COMMON-LISP@SU-AI
It seems to me the "problem" of loss of sharing when you print displaced
arrays and try to read them back in is classical. Normal printing of any
data structure that shares non-atomic parts with itself or anything else,
followed by reading it back in, causes the sharing to be lost. We've
accepted that fact since day one and seeing it crop up with displaced
arrays shouldn't upset us. We should expect that when an array is printed
out all information about its structure (dimensions) and contents (elements)
should be included in the printing, except that information about shared
structure will be lost if the normal printer is used. Some really smart
printer might be able to recognize shared structure and arrange to preserve
it on reading back in, but normally we shouldn't expect such a printer to
be available for all possible cases of sharing that can occur.
If a program has a crazy-quilt of displaced arrays sharing structure,
the programmer shouldn't expect to be able to print out the structure
and later read it back in. But the programmer should be able to expect
to be able to print out the structure for purpose of eyeballing it
during debugging, and not have critical information lost, such as
which axis are of length zero.
Thus the proposal to use #.(MAKE-ARRAY ...) or whatever seems reasonable
in cases where normal print representation loses critical information.
-------
∂12-Jun-85 1353 AS%hp-hulk.csnet@csnet-relay.arpa Re: Does Defmacro establish a block?
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 13:53:00 PDT
Received: from hplabs by csnet-relay.csnet id ak28624; 12 Jun 85 16:48 EDT
Received: by HP-VENUS id AA16535; Wed, 12 Jun 85 09:23:17 pdt
Message-Id: <8506121623.AA16535@HP-VENUS>
Date: Wed 12 Jun 85 09:24:07-PDT
From: Alan Snyder <AS%hplabs.csnet@csnet-relay.arpa>
Subject: Re: Does Defmacro establish a block?
To: common-lisp@su-ai.ARPA
In-Reply-To: Message from ""David A. Moon" <Moon@stony-brook.scrc.symbolics.com@HP-VENUS>" of Tue 11 Jun 85 14:32:35-PDT
Source-Info: From (or Sender) name not authenticated.
I believe that all defining forms that have a name and a body should put
a named block around the body.
I fail to see the advantage of all these named blocks being created
implicitly. Too many implicit definitions can be confusing. Is it
really too much to ask the programmer to put in an explicit block on
those occasions when he/she wants to do a return from one of these
constructs? Does it happen that often? Are there some situations (I
hope not!) where the system can put a block where the programmer cannot
(and where it makes sense to return to)?
-------
∂12-Jun-85 1459 RAM@CMU-CS-C.ARPA Does Defmacro establish a block?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 14:59:13 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 12 Jun 85 17:58:32-EDT
Date: Wed, 12 Jun 1985 17:58 EDT
Message-ID: <RAM.12118632846.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Alan Snyder <AS%hplabs.csnet@CSNET-RELAY.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Does Defmacro establish a block?
In-reply-to: Msg of 12 Jun 1985 12:24-EDT from Alan Snyder <AS%hplabs.csnet at csnet-relay.arpa>
It is clearly stated in the manual that defun establishes a block
named with the function name. This is a feature which I use
extensively. The question is "Which of the other def-mumbles establish
a block as well, and if not why not?"
Moon's answer is "They all do." Admittedly returning out of the
body of a deftype will probably not often be useful, but this
definition has the advantage that it is consistent. This consistency
doesn't cost anything, so we might as well do thing this way.
Rob
∂12-Jun-85 1704 @MIT-MC.ARPA:BROOKS@MIT-OZ declaration pervasiveness.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 17:04:32 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 12 JUN 85 19:46:52 EDT
Date: Wed 12 Jun 85 19:44:14-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: declaration pervasiveness.
To: common-lisp@SU-AI.ARPA
cc: jk@SU-AI.ARPA
I'm having trouble deciding exactly how pervasive certain declarations
are. For instance:
(defun f (n)
(flet ((f (m) (* m m)))
(declare (ftype (function (integer) integer) f))
(declare (notinline f))
(+ (f n)
(flet ((f (m) (bar m m)))
(f n)))))
By analogy to type it would appear that the ftype declaration applies
to the call to the (* m m) f, but not to the (bar m m) call. There is
specific language in the first paragraph of page 159 that implies
that. However notinline , which has precisely the same language
applied to it at the top of page 160, is earlier singled out has
having nothing to do with bindings and being pervasive on page 155.
So does the notinline apply to the call to the (bar m m) version or
not? If not, then page 155, and the notion of pervasiveness seem
misleading.
-------
∂13-Jun-85 0542 BSG@SCRC-STONY-BROOK.ARPA Re: Does Defmacro establish a block?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 05:42:11 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 253452; Thu 13-Jun-85 08:39:18-EDT
Date: Thu, 13 Jun 85 08:43 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Re: Does Defmacro establish a block?
To: AS%hplabs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8506121623.AA16535@HP-VENUS>
Message-ID: <850613084351.1.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Wed 12 Jun 85 09:24:07-PDT
From: Alan Snyder <AS%hplabs.csnet@csnet-relay.arpa>
I believe that all defining forms that have a name and a body should put
a named block around the body.
I fail to see the advantage of all these named blocks being created
implicitly. Too many implicit definitions can be confusing.
Can you provide an example of how an implicit named block around, say,
a DEFMACRO, will ever confuse anyone, in any case, forced as it may be?
"Why, suppose somebody shouted 'ALAKAZAM00112233MXYZPTLK' by accident!"
∂13-Jun-85 0821 DCP@SCRC-STONY-BROOK.ARPA declaration pervasiveness.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 08:21:41 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 253562; Thu 13-Jun-85 11:18:40-EDT
Date: Thu, 13 Jun 85 11:20 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: declaration pervasiveness.
To: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>, common-lisp@SU-AI.ARPA
cc: jk@SU-AI.ARPA
In-Reply-To: The message of 12 Jun 85 19:44-EDT from Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Message-ID: <850613112008.7.NFEP@NEPONSET.SCRC.Symbolics.COM>
Date: Wed 12 Jun 85 19:44:14-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
I'm having trouble deciding exactly how pervasive certain declarations
are. For instance:
(defun f (n)
(flet ((f (m) (* m m)))
(declare (ftype (function (integer) integer) f))
(declare (notinline f))
(+ (f n)
(flet ((f (m) (bar m m)))
(f n)))))
By analogy to type it would appear that the ftype declaration applies
to the call to the (* m m) f, but not to the (bar m m) call. There is
specific language in the first paragraph of page 159 that implies
that. However notinline , which has precisely the same language
applied to it at the top of page 160, is earlier singled out has
having nothing to do with bindings and being pervasive on page 155.
So does the notinline apply to the call to the (bar m m) version or
not? If not, then page 155, and the notion of pervasiveness seem
misleading.
-------
If you follow the language defined in the book, you will find that your
function is illegal. Declarations are not permitted after FLET, LABELS,
or MACROLET. A lot of the language in the book seems to assume that
these forms don't exist.
Once you admit their existance, it is clear (to me at least) that
several things follow. First, FTYPE and [NOT]INLINE declarations should
be able to follow them and second, that these declarations should not be
pervasive.
∂13-Jun-85 0933 FAHLMAN@CMU-CS-C.ARPA declaration pervasiveness.
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 09:32:53 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 13 Jun 85 12:32:33-EDT
Date: Thu, 13 Jun 1985 12:32 EDT
Message-ID: <FAHLMAN.12118835652.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David C. Plummer in disguise" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: declaration pervasiveness.
In-reply-to: Msg of 13 Jun 1985 11:20-EDT from David C. Plummer in disguise <DCP at SCRC-QUABBIN.ARPA>
If you follow the language defined in the book, you will find that your
function is illegal. Declarations are not permitted after FLET, LABELS,
or MACROLET. A lot of the language in the book seems to assume that
these forms don't exist.
Once you admit their existance, it is clear (to me at least) that
several things follow. First, FTYPE and [NOT]INLINE declarations should
be able to follow them and second, that these declarations should not be
pervasive.
This seems to me like the only sensible interpretation, even if the
language in the book is contradictory. What we have here is a very
strong analogy with variable-binding forms, and we need similar
machinery for declaring things about a particular lexical binding of a
function name. Obviously the language about declarations in the book
was written before we had really faced up to the existence of lexically
scoped function definitions.
I'm not so sure about MACROLET, however. It's not clear that FTYPE and
INLINE make any sense here.
-- Scott
∂13-Jun-85 0935 @MIT-MC.ARPA:BROOKS@MIT-OZ Re: declaration pervasiveness.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 09:35:35 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 13 JUN 85 12:34:49 EDT
Date: Thu 13 Jun 85 12:32:11-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: declaration pervasiveness.
To: DCP@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA
cc: jk@SU-AI.ARPA
In-Reply-To: Message from "David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>" of Thu 13 Jun 85 11:23:12-EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: declaration pervasiveness.
If you follow the language defined in the book, you will find that your
function is illegal. Declarations are not permitted after FLET, LABELS,
or MACROLET. A lot of the language in the book seems to assume that
these forms don't exist.
?? In my copy of the book (the one from digital press) all of FLET,
LABELS and MACROLET are included in a list at the top of page 154
which claim to be the forms in which declarations can appear at the
beginning of a body. However page 113 does seem to disagree with
this--there the only declarations are in the definition parts of the
functional `variables'.
Once you admit their existance, it is clear (to me at least) that
several things follow. First, FTYPE and [NOT]INLINE declarations should
be able to follow them and second, that these declarations should not be
pervasive.
That sounds reasonable to me too. But that's not what page 155
currently says.
-------
∂13-Jun-85 1139 gls@THINK.ARPA declaration pervasiveness.
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 11:39:38 PDT
Received: by THINK.ARPA with CHAOS id AA17400; Thu, 13 Jun 85 14:29:45 edt
Date: Thu, 13 Jun 85 14:30 EDT
From: Guy Steele <gls@THINK.ARPA>
Subject: declaration pervasiveness.
To: common-lisp@SU-AI.ARPA
Cc: jk@SU-AI.ARPA, gls@THINK.ARPA
In-Reply-To: Your message of 12 Jun 85 19:44-EDT
Message-Id: <850613143035.1.GLS@YON.ARPA>
Received: from GODOT by AQUINAS via CHAOS with CHAOS-MAIL; Wed 12-Jun-85 20:08:52-EDT
Received: from SU-AI.ARPA (su-ai.arpa.ARPA) by THINK.ARPA id AA09914; Wed, 12 Jun 85 20:03:40 edt
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 17:04:32 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 12 JUN 85 19:46:52 EDT
Date: Wed 12 Jun 85 19:44:14-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA@think>
Subject: declaration pervasiveness.
To: common-lisp@SU-AI.ARPA
Cc: jk@SU-AI.ARPA
I'm having trouble deciding exactly how pervasive certain declarations
are. For instance:
(defun f (n)
(flet ((f (m) (* m m)))
(declare (ftype (function (integer) integer) f))
(declare (notinline f))
(+ (f n)
(flet ((f (m) (bar m m)))
(f n)))))
By analogy to type it would appear that the ftype declaration applies
to the call to the (* m m) f, but not to the (bar m m) call. There is
specific language in the first paragraph of page 159 that implies
that. However notinline , which has precisely the same language
applied to it at the top of page 160, is earlier singled out has
having nothing to do with bindings and being pervasive on page 155.
So does the notinline apply to the call to the (bar m m) version or
not? If not, then page 155, and the notion of pervasiveness seem
misleading.
-------
The notinline declaration does not apply to the call to the (bar m m) version.
The description of notinline specifically notes that lexical scoping is observed
regarding the references to function names occurring in the declaration.
So the declaration (notinline f) refers to the function named f that is visible
at that point, namely the (* m m) version. The declaration is pervasive in that
it affects all *calls* to that specific f (not *bindings* of other functions
also named f) in the body of the construct. The call to the (bar m m) version
is not a call to the f referred to by the notinline declaration, but to some
other f, and so is not affected by that declaration.
--Guy
∂13-Jun-85 1246 @MIT-MC.ARPA:BROOKS@MIT-OZ Re: declaration pervasiveness.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 12:46:47 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 13 JUN 85 15:47:39 EDT
Date: Thu 13 Jun 85 15:44:59-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: declaration pervasiveness.
To: gls@THINK.ARPA
cc: common-lisp@SU-AI.ARPA, jk@SU-AI.ARPA
In-Reply-To: Message from "Guy Steele <gls@THINK.ARPA>" of Thu 13 Jun 85 14:39:33-EDT
The notinline declaration does not apply to the call to the (bar m m) version.
The description of notinline specifically notes that lexical scoping is observed
regarding the references to function names occurring in the declaration.
So the declaration (notinline f) refers to the function named f that is visible
at that point, namely the (* m m) version. The declaration is pervasive in that
it affects all *calls* to that specific f (not *bindings* of other functions
also named f) in the body of the construct. The call to the (bar m m) version
is not a call to the f referred to by the notinline declaration, but to some
other f, and so is not affected by that declaration.
--Guy
Ok. Thats sounds reasonable. But what's the difference between a
pervasive and a non-pervasive declaration then? Your description
would fit a type declaration also, which the manual says is not
pervasive. As I read it the only difference is that in addition to
what you say above, the declaration of notinline, since it is
pervasive (page 155), also applies to calls to that specific f within the local
function definitions of an FLET or LABELS (which are outside the
body). By your lexical scoping argument this only affects LABELS
as that particular f is not visible in the FLET function definitions.
Could you comment on whether these declarations are even legal in the
body of an FLET, LABELS or MACROLET since pages 113 and 154 seem to
be contradictory.
On random typography: in the table at the top of page 154, do*
preceeds do whereas let* and prog* come after let and prog
respectively.
-------
∂13-Jun-85 1428 AS%hp-hulk.csnet@csnet-relay.arpa conflicting declarations
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 14:27:41 PDT
Received: from hplabs by csnet-relay.csnet id ah05457; 13 Jun 85 17:18 EDT
Received: by HP-VENUS id AA28111; Wed, 12 Jun 85 15:55:22 pdt
Message-Id: <8506122255.AA28111@HP-VENUS>
Date: Wed 12 Jun 85 15:56:27-PDT
From: Alan Snyder <AS%hplabs.csnet@csnet-relay.arpa>
Subject: conflicting declarations
To: common-lisp@su-ai.ARPA
Source-Info: From (or Sender) name not authenticated.
I could not find anything in Chapter 9 to cover the case of multiple
declarations for the same variable binding, particularly the case of
conflicting declarations. Examples:
1. (defun foo (x)
(declare (type float x))
(declare (type float x)) ; redundant
...
2. (defun foo (x)
(declare (type float x))
(declare (type integer x)) ; conflicting
...
3. (defun foo (x)
(declare (type number x))
(declare (type integer x)) ; restricting
...
4. (defun foo (x)
(declare (type integer x))
(declare (type number x)) ; enlarging
...
Any opinions on what the definition does or should say in such cases?
Should any set of individually legal declarations be legal, with the
textually last declaration taking effect in cases of conflict? Should
an error be signalled if multiple declarations of the same "kind" are
found? If so, in all cases above?
(I find example 3 remotely reasonable. Perhaps the first declaration is
machine-generated and the second was added by the programmer who knew
more?)
-------
∂13-Jun-85 1447 FAHLMAN@CMU-CS-C.ARPA conflicting declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 14:47:01 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 13 Jun 85 17:45:58-EDT
Date: Thu, 13 Jun 1985 17:45 EDT
Message-ID: <FAHLMAN.12118892697.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Alan Snyder <AS%hplabs.csnet@CSNET-RELAY.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: conflicting declarations
In-reply-to: Msg of 12 Jun 1985 18:56-EDT from Alan Snyder <AS%hplabs.csnet at csnet-relay.arpa>
I would say that the current status is that it "is an error". We might
want to specify that redundant declarations are harmless, the
conflicting case is (signals?) an error, and if the declared types are
hierarchically related, the more restrictive governs. But right now, I
don't think the user has the right to count on any particular behavior
in these cases.
-- Scott
∂13-Jun-85 1942 Moon@SCRC-STONY-BROOK.ARPA What package are feature names resident in?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 19:42:20 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 254089; Thu 13-Jun-85 22:39:13-EDT
Date: Thu, 13 Jun 85 22:42 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: What package are feature names resident in?
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 25 Apr 85 07:19-EST from Jon White <JLW@SU-AI.ARPA>,
<RAM.12106292554.BABYL@CMU-CS-C.ARPA>
Message-ID: <850613224203.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Was the following issue ever resolved? I don't think I saw anything
about it other than these two messages.
Date: 25 Apr 85 0419 PST
From: Jon White <JLW@SU-AI.ARPA>
Bottom of page 358 clearly suggests that #+ should READ in the expression
following the +, and obtain symbols which are tested for MEMBERship in
the *features* list. So what should happen from the following fragment:
(in-package "LUSER")
(push 'dull *features*)
(in-package "WINNER")
(push 'snazzy *features*)
(in-package "USER")
'(a #+dull b #+snazzy c )
Now, how long a list is the last form read?
Consider when package LUSER is, and is not, a user of package LISP; and
when "dull" is, and is not, an external symbol of the LISP package.
I believe I see two schools of thought, exemplified in the several
implemetations I've looked at so far. One says that feature names can be
any lisp objects, and since luser:snazzy and winner:snazzy are two separate
features, you have to be careful about which one you really mean. The
other school says that feature names are analogous to the names of
packages -- a kind of global namespace -- and will probably implement #+
by binding *package* to some canonical place (like, the keyword package).
I'm not sure I can give an adequate defense of either position, but
the fact that two different implementations initialize their *features*
lists to symbols in different packages makes it difficult to interpret
forms like
#+Lispm (do-this)
because you don't which symbol the "Lispm" will turn into. Should you
have to say
#+:Lispm (do-this)
I don't think this was intended (to have to put package qualifiers for
feature names), but if there are two differing implemetations . . .
Date: Fri, 26 Apr 1985 15:11 EST
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
I believe that the issue discussed was "Should features always be
keywords?" The conclusion was "No, but they can be." An implication
of this decision is that features are packaged symbols.
The manual is not clear on this point. I think the most likely reading
of what the manual says is that features are packaged symbols. However,
I don't believe that that can be workable in practice. As JonL pointed
out, it's difficult to deal with this unless you make every feature a
keyword, but then you have a lot of extra colons flying around. In some
cases the package in which a feature symbol would be defined will not
even be defined if the feature is not present. An example:
;; Use fast matrix multiplication if present, else do it by hand
(defmacro mm (m1 m2 m3)
#+fastarithmetic:fastarithmetic
`(fastarithmetic:matrix-multiply ,m1 ,m2 ,m3)
#-fastarithmetic:fastarithmetic
`(dotimes (i (array-dimension ,m1 0))
(dotimes (j (array-dimension ,m2 1))
(let ((sum 0))
(dotimes (k (array-dimension ,m1 1))
(incf sum (* (aref ,m1 i k) (aref ,m2 k j))))
(setf (aref ,m3 i j) sum)))))
A flat namespace for feature names would avoid these problems, and surely
would have no more name conflicts than the existing flat namespaces for
packages and modules.
I'd like to propose that the manual be "clarified" on pp.358-9 to say that
#+ and #- are not sensitive to packages when reading @I[feature]; this
applies both to feature names and to the AND, OR, and NOT operators.
Incidentally, in our implementation feature names can be numbers; these
are not sensitive to radix. (This is so we can say #+3600; I'd hate for
this to be illegal syntax in another Common Lisp implementation.)
The manual should also be "clarified" on p.448 to say that the symbols
on *features* should be keywords and that any numbers present should
be notated in decimal. Does anyone object to this?
∂14-Jun-85 0610 greek@DEC-HUDSON What's in *FEATURES*?
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 06:09:59 PDT
Date: Fri, 14 Jun 85 09:09:45 EDT
From: greek@DEC-HUDSON
Subject: What's in *FEATURES*?
To: common-lisp@su-ai
It seems to me that, since *FEATURES* is a "global" variable, the items
in the list should not be package-specific. The features should pertain
to the LISP system as a whole, specifying things which parameterize the
system.
If a package wants to itemize features within it, that should be done
with something inside the package (special variable or function).
Furthermore, even the existence of a package isn't a feature, but rather
is noted by the presence of its name in *MODULES*. It's not even
clear to me that *FEATURES* isn't a constant, but that might be a little
radical.
In light of my opinion, features can only be simple symbols, all present
in the LISP package. Right?
- Paul
∂14-Jun-85 0900 gls@THINK.ARPA [hpfclp!paul%hplabs.csnet: LCM]
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 09:00:49 PDT
Received: by THINK.ARPA with CHAOS id AA25189; Fri, 14 Jun 85 11:54:53 edt
Date: Friday, 14 June 1985, 11:56-EDT
From: Guy Steele <gls@THINK.ARPA>
Subject: [hpfclp!paul%hplabs.csnet: LCM]
To: common-lisp@sail
Cc: gls@THINK.ARPA
In-Reply-To: <FAHLMAN.12118891589.BABYL@CMU-CS-C.ARPA>
Message-Id: <850614115605.1.GLS@DESIDERIUS.ARPA>
Date: Thu, 13 Jun 1985 17:39 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA@think>
This one's for you. I can't remember how or whether this discussion
finally got resolved.
---------------------------------------------------------------------------
Date: Thursday, 13 June 1985 09:48-EDT
From: hpfclp!paul%hplabs.csnet at csnet-relay.arpa
To: hplabs!Fahlman
Re: LCM
MMDF-Warning: Parse error in preceding line at CSNET-RELAY.ARPA
Source-Info: From (or Sender) name not authenticated.
Scott,
Is the definition of LCM (12.4) being modified so that it will
accept 0 arguments? If so, is the result 1?
Paul Beiser
Hewlett-Packard
Ft. Collins, Colorado
uucp: ...{ihnp4,hplabs}!hpfcla!paul
arpa: "hpfclp!paul%hplabs.csnet"@csnet-relay
I believe everyone agrees that *if* LCM is to accept zero arguments
then it should return 1. I strongly recommend that all implementors
support this case as an extension to Common Lisp, and intend to
recommend the change when we update Common Lisp.
--Guy
∂14-Jun-85 1010 Moon@SCRC-STONY-BROOK.ARPA What's in *FEATURES*?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 10:10:13 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 254385; Fri 14-Jun-85 13:07:02-EDT
Date: Fri, 14 Jun 85 13:09 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: What's in *FEATURES*?
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 14 Jun 85 09:09-EDT from greek@DEC-HUDSON
Message-ID: <850614130943.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 14 Jun 85 09:09:45 EDT
From: greek@DEC-HUDSON
It seems to me that, since *FEATURES* is a "global" variable, the items
in the list should not be package-specific. The features should pertain
to the LISP system as a whole, specifying things which parameterize the
system.
If a package wants to itemize features within it, that should be done
with something inside the package (special variable or function).
Furthermore, even the existence of a package isn't a feature, but rather
is noted by the presence of its name in *MODULES*. It's not even
clear to me that *FEATURES* isn't a constant, but that might be a little
radical.
In light of my opinion, features can only be simple symbols, all present
in the LISP package. Right?
The problem with that idea is that putting a symbol into the LISP package makes
that symbol be shared among all packages except those that explicitly shadow it.
Thus it is not a good idea to put a lot of extra symbols into the LISP package
in addition to the ones listed in the manual. If *FEATURES* were a constant,
controlled solely by the implementation, the problem would simply be that
different implementations would have different symbols in the LISP package,
which could be lived with (it happens anyway). But the #+ and #- syntaxes are
quite convenient and many large programs want to push their own symbols onto
*FEATURES*. I don't think it's at all a good idea for such symbols to also be
exported from the LISP package. And it would be silly to have two versions of
#+, one for "system features" and the other for "user features."
The main reason the KEYWORD package exists is to serve as a flat namespace
that, unlike the LISP package, has no effect on inter-package sharing. Thus
I think the KEYWORD package is the right one for features.
∂14-Jun-85 1120 KMP@SCRC-STONY-BROOK.ARPA What's in *FEATURES*?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 11:19:57 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 254453; Fri 14-Jun-85 14:16:48-EDT
Date: Fri, 14 Jun 85 14:19 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: What's in *FEATURES*?
To: Moon@SCRC-STONY-BROOK.ARPA, greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850614130943.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <850614141940.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Fri, 14 Jun 85 13:09 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: Fri, 14 Jun 85 09:09:45 EDT
From: greek@DEC-HUDSON
It seems to me that, since *FEATURES* is a "global" variable, the items
in the list should not be package-specific. The features should pertain
to the LISP system as a whole, specifying things which parameterize the
system.
If a package wants to itemize features within it, that should be done
with something inside the package (special variable or function).
Furthermore, even the existence of a package isn't a feature, but rather
is noted by the presence of its name in *MODULES*. It's not even
clear to me that *FEATURES* isn't a constant, but that might be a little
radical.
In light of my opinion, features can only be simple symbols, all present
in the LISP package. Right?
The problem with that idea is that putting a symbol into the LISP package makes
that symbol be shared among all packages except those that explicitly shadow it.
Thus it is not a good idea to put a lot of extra symbols into the LISP package
in addition to the ones listed in the manual. If *FEATURES* were a constant,
controlled solely by the implementation, the problem would simply be that
different implementations would have different symbols in the LISP package,
which could be lived with (it happens anyway). But the #+ and #- syntaxes are
quite convenient and many large programs want to push their own symbols onto
*FEATURES*. I don't think it's at all a good idea for such symbols to also be
exported from the LISP package. And it would be silly to have two versions of
#+, one for "system features" and the other for "user features."
The main reason the KEYWORD package exists is to serve as a flat namespace
that, unlike the LISP package, has no effect on inter-package sharing. Thus
I think the KEYWORD package is the right one for features.
I dislike the idea of saying package doesn't matter on features. There was a big
hassle in Maclisp years ago because two compatible implementations of strings both
wanted to use the name STRING. If one could have done #+JOE:STRING and #+BILL:STRING,
we'd have been OK.
I'm willing to go so far as to say that common features which we wish to standardize
meanings for might want to go on the keyword package and that user-defined features
could be legislated not to be allowed there. From this, we could further define that
#+ and #- would do the effect of
(LET ((PACKAGE (FIND-PACKAGE "KEYWORD"))) (READ))
so that #+FOO was like #+:FOO. So, for example, if COMPLEX was something we expected
some implementations to fail to provide for some reason, we might say legislate
that implementations providing it must have a :COMPLEX feature and people could use
#+COMPLEX.
But people providing private features would be forced to do #+FOO:COMPLEX.
We should stipulate that package-not-found errors after #+ and #- are to be treated
as if the feature were missing.
Would people buy this or some close variation thereof? It gets around the problem of
having to make feature names go on LISP (since everything is on keyword) without
losing package information and without causing people to type package names in common
(pun?) situations.
∂14-Jun-85 1317 greek@DEC-HUDSON Putting features in the keyword package.
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 13:16:36 PDT
Date: Fri, 14 Jun 85 16:16:12 EDT
From: greek@DEC-HUDSON
Subject: Putting features in the keyword package.
To: common-lisp@su-ai
Dave Moon and others have suggested that features should be symbols
in the keyword package. I see some problems with this:
1. People seem to think that packages and subsystems will want to
add things to *FEATURES* because that make conditionalizing
code using the packages easier. Fine, but that's a real good
reason why the features ought to be in that package. Otherwise
packages will have duplicate features names and things will get
confused. Packages are to isolate names!
2. If features are in the keyword package, are they keywords? I
suppose so. Thus we get things like #+:COMPILER.
I really think package-specific stuff ought to stay in that package.
Perhaps we should extend #+ so I can write #+(FOO:FEATURE-P :OPTION1)
to find out if package FOO has OPTION1 now. That syntax won't work,
but you know what I mean.
If I could evaluate an arbitrary form with #+, then I could also write
things like #+(STRING= (SOFTWARE-TYPE) "VMS"). Otherwise we need
redundant information in *FEATURES* to specify the operating system, etc.
If we need to make arbitrary decision with #+, then let's bite the
bullet and allow that.
- Paul
∂14-Jun-85 1439 REM@IMSSS Features in keyword package? Yes.
Received: from IMSSS by SU-AI with PUP; 14-Jun-85 14:38 PDT
Date: 14 Jun 1985 1438-PDT
From: Rem@IMSSS
Subject: Features in keyword package? Yes.
To: COMMON-LISP@SU-AI
It seems to me the essential thing about keywords is that they are
interned (hashed) thus can be uniquely recognized, but don't have any
other objects (values functions or properties) associated with them.
This places them somewhat between strings and normal identifiers (symbols).
Anyway, features seem to have the same essential things, they need to
be recognized but they needn't have values etc. assigned to them. So it
makes sense to put them in the keyword package, and to default the
current package to the keyword package in places where they are expected
so that the user needn't type the : prefix, such as after #+.
(This is analagous to not needing the : prefix after &KEY in a lambda
expression; But actually I'm a little confused by the example on page
65 at the bottom, where : prefix isn't used inside the body either.
I presume START and END are lexical variables in the current package,
not in the KEYWORD package, thus somehow the lambda expression establishes
a temporary linkage between similarily-named variables in two different
packages, without actually importing them as a permanent side-effect.
It's possible my confusion here invalidates my opinion. Can somebody explain
this strangeness?)
-------
∂14-Jun-85 1503 Masinter.pa@Xerox.ARPA What #+rmhackery a good idea #-rmhackery utter nonsense
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 15:03:23 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 JUN 85 15:03:18 PDT
Date: 14 Jun 85 15:03 PDT
From: Masinter.pa@Xerox.ARPA
Subject: What #+rmhackery a good idea #-rmhackery utter nonsense
to: Greek@DEC-HUDSON.ARPA
cc: COMMON-LISP@SU-AI.ARPA
Message-ID: <850614-150318-1105@Xerox>
The #+rmhackery feature #-rmhackery lossage of "#+" and "#-" is one of
the more dubious in GSSB. Expanding it with #+(good-ideap ':rmhackery)
the obvious extension #-(good-ideap ':rmhackery) the awful extension of
allowing arbitrary expressions in the feature-forms removes any hope of
being able to do anything with a file of code than #+(good-ideap
':rmhackery) allows the natural extension to more complex situations
#-(good-ideap ':rmhackery) load it.
What happened to the natural constructs
(IF (STRING= (SOFTWARE-TYPE) "VMS") <YESVMS> <NOVMS>)
One could even imagine (whoa) a compiler that would expand
(SOFTWARE-TYPE) into a constant, and evaluate STRING= at compile time if
the args were constant (!)
Of course, there's always
#+#.(STRING= (SOFTWARE-TYPE) "VMS").
∂14-Jun-85 1810 DCP@SCRC-STONY-BROOK.ARPA What #+rmhackery a good idea #-rmhackery utter nonsense
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 18:10:15 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 254716; Fri 14-Jun-85 21:07:05-EDT
Date: Fri, 14 Jun 85 21:09 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: What #+rmhackery a good idea #-rmhackery utter nonsense
To: Masinter.pa@XEROX.ARPA, Greek@DEC-HUDSON.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: <850614-150318-1105@Xerox>
Message-ID: <850614210948.4.NFEP@NEPONSET.SCRC.Symbolics.COM>
Date: 14 Jun 85 15:03 PDT
From: Masinter.pa@Xerox.ARPA
The #+rmhackery feature #-rmhackery lossage of "#+" and "#-" is one of
the more dubious in GSSB. Expanding it with #+(good-ideap ':rmhackery)
the obvious extension #-(good-ideap ':rmhackery) the awful extension of
allowing arbitrary expressions in the feature-forms removes any hope of
being able to do anything with a file of code than #+(good-ideap
':rmhackery) allows the natural extension to more complex situations
#-(good-ideap ':rmhackery) load it.
I'm not sure what you mean. Anyway, in our implementation, #+ and #-
does a READ with *package* bound to the keyword package as well as
turning off #. (see below). It then uses STRING-EQUAL as the comparison
function with the symbols (presumed, but not forced [I think] to be
keywords) in *FEATURES* for the appropriate tokens (e.g., :LISPM and
:NIL are the appropriate tokens of #+(or LispM NIL)). We've had this
for years and it doesn't seem to have any problems.
What happened to the natural constructs
(IF (STRING= (SOFTWARE-TYPE) "VMS") <YESVMS> <NOVMS>)
It doesn't allow
#+LispM (progn
... 20 pages of LispM specific code ...
)
#-LispM (progn
... 20 pages of generic CL code ...
)
One could even imagine (whoa) a compiler that would expand
(SOFTWARE-TYPE) into a constant, and evaluate STRING= at compile time if
the args were constant (!)
Our compiler would do this today if somebody put STRING= in the list of
functions to apply constant folding to.
Of course, there's always
#+#.(STRING= (SOFTWARE-TYPE) "VMS").
Says who? In our implementation, #. is turned off while reading #+ or
#-. Suppose I shipped some code that said
#-LispM #.(error nil "This code hasn't been made to run on non-LispMs yet.")
Perhaps a better example would be building machine dependent data
structures inside #+ or #-:
(defun hairy-thing ()
#+LispM '#.(compute-hairy-thing-for-LispM)
#-LispM '#.(compute-generic-hairy-thing))
∂14-Jun-85 1846 FAHLMAN@CMU-CS-C.ARPA features
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 18:46:31 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 14 Jun 85 21:46:27-EDT
Date: Fri, 14 Jun 1985 21:46 EDT
Message-ID: <FAHLMAN.12119198633.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: features
It was clear at the time we let #+ and #- into the language that these
were total kludges and were being kept around almost entirely for
reasons of compatibility with existing code. For the cases that they
can handle, they are convenient enough, but I think it would be a major
mistake to try to extend them by letting them take an arbitrary
extension to evaluate, as Paul the Greek proposes. There are many
problems, among them being the problem of which Lisp interpreter is used
to evaluate the expression in question if the #+ stuff is being used to
allow the same file to work in, say, Common Lisp and Maclisp.
I think that by far the simplest solution is to make #+foo treat the
symbol FOO as a keyword, despite the lack of a leading colon in this
context. This minimizes the possibilities for subtle package lossage of
the type Moon describes. Yes, it would then be possible that packages
developed in total ignorance of each other might choose confliciting
feature keywords; on the other hand, such packages have an equally great
chance of choosing conflicting package names, so there has to be some
modest amount of coordination if they are to run together. I think that
this is a change and not a clarification, however -- there's no way to
read the current manual as specifying this conversion to keywords.
I think that putting all these symbols in the Lisp package (as external
symbols) is not workable. For ont thing, this will often result in some
internal symbol in Lisp being unintentionally made external, and then
when another package imports Lisp it is in for some unpleasant
surprises.
The manual is quite clear that the features are to be symbols (or lists
that are boolean combinations of symbols), and I don't see any reason to
extend that. #+3600 can read the string "3600" as the name of a
(keyword) symbol. This avoids all radix lossage.
-- Scott
∂14-Jun-85 2043 KMP@SCRC-STONY-BROOK.ARPA features
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 20:43:17 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 254772; Fri 14-Jun-85 23:40:09-EDT
Date: Fri, 14 Jun 85 23:43 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: features
To: Fahlman@CMU-CS-C.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12119198633.BABYL@CMU-CS-C.ARPA>
References: <850614141940.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <850614234301.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Fri, 14 Jun 1985 21:46 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
It was clear at the time we let #+ and #- into the language that these
were total kludges and were being kept around almost entirely for
reasons of compatibility with existing code.
I disagree with this. #+ and #- are necessary because implementations invariably
differ in all kinds of unexpected ways and sometimes it is necessary (both in
program and data files) to completely blindfold READ to gross kludges. While I
think it's reasonable to describe this as a total kludge, I think you're kidding
yourself to think such kludges are a thing of the past and something that will
not continue to occur. In spite of a desire I'm sure we all have to never resort
to these tools, they serve a vital function and should be made as convenient and
as well-defined as possible for those situations where they turn out to be needed.
... I think it would be a major mistake to try to extend them by letting them
take an arbitrary extension to evaluate ...
I certainly agree with this part. #. can handle the more complicated situations.
I think that by far the simplest solution is to make #+foo treat the
symbol FOO as a keyword, despite the lack of a leading colon in this
context. This minimizes the possibilities for subtle package lossage of
the type Moon describes. Yes, it would then be possible that packages
developed in total ignorance of each other might choose confliciting
feature keywords; on the other hand, such packages have an equally great
chance of choosing conflicting package names, so there has to be some
modest amount of coordination if they are to run together. I think that
this is a change and not a clarification, however -- there's no way to
read the current manual as specifying this conversion to keywords...
Statements like "yes, it would then be possible ..." and such which suggest
that you want to ignore the "hard cases" completely miss the point. #+ and #-
have their major use in the strangest situations and flattening the namespace
will not serve to make things better.
I think that putting all these symbols in the Lisp package (as external
symbols) is not workable. For ont thing, this will often result in some
internal symbol in Lisp being unintentionally made external, and then
when another package imports Lisp it is in for some unpleasant
surprises....
As I said in an earlier message, I am content to have a fixed and advertised
set of Common-Lisp approved features reside on the keyword package, but I
very strongly oppose any use of the keyword package for any application which
involves an user-extensible set of names (such as the features list).
In my opinion, user-defined features should must be packaged (and expressly
not on the keyword package); refer to my earlier message on this subject for
details.
The manual is quite clear that the features are to be symbols (or lists
that are boolean combinations of symbols), and I don't see any reason to
extend that. #+3600 can read the string "3600" as the name of a
(keyword) symbol. This avoids all radix lossage.
I guess I really don't like this because it destroys the simple user model that
READ is involved and it makes one wonder if #+FOO:3600 will read as FOO:/3600
or just :/3600.
∂15-Jun-85 1859 Masinter.pa@Xerox.ARPA Re: What #+rmhackery a good idea #-rmhackery utter nonsense
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 15 Jun 85 18:59:13 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 15 JUN 85 18:59:13 PDT
Date: 15 Jun 85 18:59 PDT
From: Masinter.pa@Xerox.ARPA
Subject: Re: What #+rmhackery a good idea #-rmhackery utter nonsense
In-reply-to: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>'s
message of Fri, 14 Jun 85 21:09 EDT
To: DCP@SCRC-STONY-BROOK.ARPA
cc: COMMON-LISP@SU-AI.ARPA
Message-ID: <850615-185913-1015@Xerox>
Sorry, my message was a bit too #+:-).
Examples of code that don't use #+ and #-:
(if (status 'lispm)
(progn ... 20 pages of lispm code ...))
(if (not (status 'lispm))
(progn ... 20 pages of generic CL code ...))
I'd prefer
(defun hairy-thing ()
(if (status 'lispm) (compute-hairy-thing-for-LispM)
(compute-generic-hairy-thing))
but if you insist:
(defmacro const (x) `',(eval x))
(defun hairy-thing ()
(cond
((status 'lispm) (const (compute-hairy-thing-for-LispM))
(t (const (compute-generic-hairy-thing))))
∂16-Jun-85 0600 DCP@SCRC-STONY-BROOK.ARPA Re: What #+rmhackery a good idea #-rmhackery utter nonsense
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Jun 85 06:00:02 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 255362; Sun 16-Jun-85 08:56:46-EDT
Date: Sun, 16 Jun 85 08:59 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Re: What #+rmhackery a good idea #-rmhackery utter nonsense
To: Masinter.pa@XEROX.ARPA, DCP@SCRC-STONY-BROOK.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: <850615-185913-1015@Xerox>
Message-ID: <850616085953.7.NFEP@NEPONSET.SCRC.Symbolics.COM>
Date: 15 Jun 85 18:59 PDT
From: Masinter.pa@Xerox.ARPA
Sorry, my message was a bit too #+:-).
No, that wasn't the problem at all. There are major problems, in my
opinion, with the three points of your message.
Examples of code that don't use #+ and #-:
(if (status 'lispm)
(progn ... 20 pages of lispm code ...))
(if (not (status 'lispm))
(progn ... 20 pages of generic CL code ...))
Problem 1a: This is all runtime. #+/#- is readtime and therefore
compile time as well.
Problem 1b: Assuming the compiler DID decide to "compile" the IF and
optimize things out, I'm not convinced the compiler should try to
compile the DEFUNs that appear inside the (PROGN ...). Normally it
would if it saw a (PROGN ...) at top level, but do your examples qualify
as top-level? They look like they're inside an IF to me.
Problem 1c: Suppose I have some LispM specific packages that are in the
LispM specific code (e.g., TV:)? Since those packages probably do not
exist in a generic CL system, I will get a read time error. #+/#-
should not (and in Symbolics' implementation do not) generate read
errors for unknown packages, and try not to cause any errors at all.
I'd prefer
(defun hairy-thing ()
(if (status 'lispm) (compute-hairy-thing-for-LispM)
(compute-generic-hairy-thing))
Problem 2a: Same as 1a. The (status 'lispm) is a runtime operation. At
the very least it has to be '#.(status 'lispm).
Problem 2b: Suppose it were '#.(status lispm). There are two choices
for the compiler. (1) it can optimize the IF immediately and only
compile the appropriate subform, or (2) it can compile both subforms and
then do the IF optimization. The problem with (1) (the general problem)
is that you won't get compiler warnings for the non-compiled subform.
The problem with (2) (somewhat specific to this entire discussion) is
that if (status 'lispm) is false, it will compile a call to
compute-hairy-thing-for-LispM. Well, I don't intend there to be such a
function in the general case. Defining such a function would run into
the package problems (see 1c above), and defining a stub to make
compiler warnings go away is a kludge.
Problem 2c: I intended the computation to happen once. You address this
below.
but if you insist:
(defmacro const (x) `',(eval x))
(defun hairy-thing ()
(cond
((status 'lispm) (const (compute-hairy-thing-for-LispM))
(t (const (compute-generic-hairy-thing))))
(3a, 3b same as 2a, 2b)
Problem 3c: This is related to 2b. This construct FORCES the compiler
to optimize the IF/COND before compiling subforms. If you don't, you
are FORCED to include stubs for "the other implementation." You can't
define the real thing because of packages. BTW, just how DO you define
the stubs without using #+ and #- that addresses the points raised in 1c
above?
∂16-Jun-85 1300 KMP@SCRC-STONY-BROOK.ARPA Re: What #+rmhackery a good idea #-rmhackery utter nonsense
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Jun 85 13:00:37 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 255421; Sun 16-Jun-85 15:57:14-EDT
Date: Sun, 16 Jun 85 16:00 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Re: What #+rmhackery a good idea #-rmhackery utter nonsense
To: Masinter.pa@XEROX.ARPA, DCP@SCRC-STONY-BROOK.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: <850615-185913-1015@Xerox>
Message-ID: <850616160008.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 15 Jun 85 18:59 PDT
From: Masinter.pa@Xerox.ARPA
... I'd prefer
(defun hairy-thing ()
(if (status 'lispm) (compute-hairy-thing-for-LispM)
(compute-generic-hairy-thing))
What if COMPUTE-HAIRY-THING-FOR-LISPM (or whatever goes in its place)
isn't defined off of the LispM or uses special variables defined only
in the LispM or ... The problem is that you get a lot of compiler
warnings that have to be muffled.
but if you insist:
(defmacro const (x) `',(eval x))
(defun hairy-thing ()
(cond
((status 'lispm) (const (compute-hairy-thing-for-LispM))
(t (const (compute-generic-hairy-thing))))
This is worse because only a very smart compiler would notice that it
didn't have to macroexpand the (STATUS 'LISPM) clause, so you'd end up
actually -executing- the LispM-only code and trying to use the functions
or reference the variables that were only defined in the LispM
implementation.
Perhaps macro-time dispatching on features so that you can write:
(FEATURE-CASE
((AND ITS MACLISP) ...code that need only work in ITS Maclisp...)
((OR MACLISP FRANZ) ...code that need only work in LispM or Franz...)
(LISPM ...code that need only work on LispM...)
(OTHERWISE ...things that got left out...))
and which will macroexpand into only the appropriate code for the compile-time
environment. Perhaps that would be a reasonable thing to argue for. It still
isn't suitable for applications where the feature you're casing off of is
something that won't be defined in the compiler but will (or might) be in the
runtime environment... Of course, such things wouldn't be appropriate for #+
or #-, either; that's the set of things that do want runtime conditionals you
mentioned above.
This doesn't obviate the need for #+ and #-, especially since they can have
uses in text which is not subject to normal semantic processing (eg, bvls,
data files stored in s-expression format, etc)... but it does lessen it a lot.
∂17-Jun-85 0022 hplabs!perdue%hplabs.csnet@csnet-relay.arpa Interesting Common LISP mail
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 00:22:18 PDT
Received: from hplabs by csnet-relay.csnet id ac22393; 17 Jun 85 3:19 EDT
Received: by HP-VENUS id AA18871; Sun, 16 Jun 85 16:27:57 pdt
Message-Id: <8506162327.AA18871@HP-VENUS>
Date: 16-Jun-85 16:25:39
To: hpfclp!twt@csnet-relay.arpa
Subject: Interesting Common LISP mail
From: perdue%hplabs.csnet@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
Here is an especially interesting piece of mail that was sent out to
the Common LISP distribution list. Note the suggestion of a more or
less official group of implementors of Common LISP for conventional
architectures.
-Cris
UUCP X.1
>From uhplabs Wed Jun 12 03:39:56 1985 remote from hpatlS
>From Moon@stony-brook.scrc.symbolics.com Wed Jun 12 00:21:21 1985 remote from hplabs
Received: by HP-VENUS id AA05084; Wed, 12 Jun 85 00:21:21 pdt
Mail-From: HP-VENUS received 12-Jun-85 00:22:24
Received: by HP-VENUS id AA05040; Wed, 12 Jun 85 00:20:56 pdt
Date: Tue, 11 Jun 85 23:51 EDT
From: "David A. Moon" <hplabs!Moon@stony-brook.scrc.symbolics.com>
Received: by HP-VENUS via CSNET; 12 Jun 1985 00:20:53-PDT (Wed)
Received: from su-ai.arpa by csnet-relay.arpa id a024133; 12 Jun 85 0:00 EDT
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 20:52:13 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252533; Tue 11-Jun-85 23:49:29-EDT
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C>
Via: CSNet; 12 Jun 85 0:20-PDT
Subject: Adjustable and displaced arrays
Cc: common-lisp@SU-AI
In-Reply-To: <FAHLMAN.12118411695.BABYL@CMU-CS-C.ARPA>
Message-Id: <850611235159.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 11 Jun 1985 21:43 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
OK, if we accept Moon's view of the proper semantics for all this, and
if we decide not to outlaw displacing to adjustable arrays, then the
Fortran machines probably have to forego cacheing and let each call to
Aref potentially grovel the headers of both arrays (or a whole chain of
arrays). Maybe that is not so bad, since none of this affects
Simple-Vectors, and they are the only kind of array that really HAS to
be fast.
However, the vendors of non-microcodable machines may feel, with some
justification, that they don't want to slow down ALL references to
non-simple arrays just so that the obscure case of adjusting an array
that is displaced to will work properly. Perhaps the right move is to
unbundle the SIMPLE declaration and allow the user to declare that an
array is NOT-DISPLACED, even if it is not simple in other respects.
Sure. I would think that an appropriate way to proceed would be for the
implementors on non-Lisp machines to get together and agree on a common
set of language extensions to deal with this sort of issue. At a later
time, those extensions can be moved into the standard language, once
they are well-debugged and agreed to be the right thing for all machines
that need them. Until that happens, programs that use the extensions won't
be portable to all implementations (but they will probably be portable to
almost all implementations if the extensions are designed right, e.g. as
ignorable declarations).
-------
∂17-Jun-85 0814 greek@DEC-HUDSON Features
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 08:13:55 PDT
Date: Mon, 17 Jun 85 11:13:39 EDT
From: greek@DEC-HUDSON
Subject: Features
To: common-lisp@su-ai
I think we will be making a BIG mistake if we put features in the
keyword package. The entire point of keywords is that they are
completely benign: their value, function, property-list, AND
mere presence or absence from the keyword package is irrelevent.
Different packages can use the same keywords with no harm whatsoever.
Now we want to invent keywords with a boolean "value": whether or
not they are present in the keyword package. Wrong!
Parameterizing a package is a fine idea, but the information ought
to be in the package. We invented packages to isolate information --
why are we trying to circumvent that now?
It is not as likely that two package names will conflict as it is
that two features will. First of all, people are likely to invent
nice unique names for their packages, particularly if the package
is a product. But features could end up being similar, such as
one describing what kind of terminal the package is being run on.
Also, we have RENAME-PACKAGE precisely for the purpose of fixing
conflicting packages names. Are we going to invent RENAME-FEATURE?
I agree with Scott that #+ seems like a real kludge. If it really
is, then we should stop this conversation at once and not try to
solve the problem we're addressing. If it isn't so bad, and people
are convinced that it's a necessary evil, then we ought to fix it
by allowing arbitrary expressions.
By the way, #+#.(predicate) won't work, because the predicate returns
T or NIL, which certainly aren't features. There may be many ways
to make complicated tests, but why not do it with #+? Probably will
be easier to read than (EVAL-WHEN (#.mumble) ...) or so other hair.
- Paul
∂17-Jun-85 0822 gls@THINK.ARPA Features in keyword package? Yes.
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 08:22:36 PDT
Received: by THINK.ARPA with CHAOS id AA06837; Mon, 17 Jun 85 11:15:17 edt
Date: Monday, 17 June 1985, 11:16-EDT
From: Guy Steele <gls@THINK.ARPA>
Subject: Features in keyword package? Yes.
To: Rem@IMSSS@THINK.ARPA, COMMON-LISP@SU-AI
Cc: gls@THINK.ARPA
In-Reply-To: The message of 14 Jun 85 17:38-EDT from Rem at IMSSS at think
Message-Id: <850617111644.1.GLS@UBALDO.ARPA>
Date: 14 Jun 1985 1438-PDT
From: Rem@IMSSS@think
... But actually I'm a little confused by the example on page
65 at the bottom, where : prefix isn't used inside the body either.
I presume START and END are lexical variables in the current package,
not in the KEYWORD package, thus somehow the lambda expression establishes
a temporary linkage between similarily-named variables in two different
packages, without actually importing them as a permanent side-effect.
That's right. Page 62, halfway down, under the discussion of how keyword
parameters are processed, states that "the name var serves to indicate the
keyword name, in that a keyword with the same name (in the keyword package)
is used as the keyword."
--Guy
∂17-Jun-85 0840 RAM@CMU-CS-C.ARPA With-Open-File :if-does-not-exist nil
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 08:39:54 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 17 Jun 85 11:39:44-EDT
Date: Mon, 17 Jun 1985 11:39 EDT
Message-ID: <RAM.12119874583.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Common-Lisp@SU-AI.ARPA
Subject: With-Open-File :if-does-not-exist nil
What should be done in With-Open-File if open returns NIL as a
consequence of a :if-does-not-exist or :if-exists or :probe keyword?
Our current implementation simply binds the result, whatever it is, to
the variable. It has been suggested that it would be better to not
evaluate the body in this case. I have my doubts about this, but the
current implementation also has problems, since it will attempt to
close NIL when the body is exited.
Rob
∂17-Jun-85 0903 gls@THINK.ARPA What #+rmhackery a good idea #-rmhackery utter nonsense
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 09:02:29 PDT
Received: by THINK.ARPA with CHAOS id AA07423; Mon, 17 Jun 85 11:53:12 edt
Date: Mon, 17 Jun 85 11:54 EDT
From: Guy Steele <gls@THINK.ARPA>
Subject: What #+rmhackery a good idea #-rmhackery utter nonsense
To: Masinter.pa@XEROX.ARPA, Greek@DEC-HUDSON.ARPA
Cc: COMMON-LISP@SU-AI.ARPA, gls@THINK.ARPA
In-Reply-To: <850614210948.4.NFEP@NEPONSET.SCRC.Symbolics.COM>
Message-Id: <850617115428.2.GLS@UBALDO.ARPA>
Date: Fri, 14 Jun 85 21:09 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA@think>
Date: 14 Jun 85 15:03 PDT
From: Masinter.pa@Xerox.ARPA
...
Of course, there's always
#+#.(STRING= (SOFTWARE-TYPE) "VMS").
Says who? In our implementation, #. is turned off while reading #+ or
#-. Suppose I shipped some code that said
#-LispM #.(error nil "This code hasn't been made to run on non-LispMs yet.")
Perhaps a better example would be building machine dependent data
structures inside #+ or #-:
(defun hairy-thing ()
#+LispM '#.(compute-hairy-thing-for-LispM)
#-LispM '#.(compute-generic-hairy-thing))
But Plummer's examples are not of the same form as Masinter's. Masinter proposes
#+#.x y
(actually, his example was incomplete, omitting the form y, which is confusing)
whereas Plummer responds with examples of the form
#+x #.y
Reading the Common Lisp manual, I find that Masinter's proposal ought to work.
Page 359 specifies that #+ "operates by first reading the feature specification
and then skipping over the form is the feature is `false.' This skipping ...
is accomplished by binding the variable *read-suppress* ..." Because the text
specifies that suppression is done while skipping, I read into this the tacit
implication that the reading of the feature does not involve suppression.
Therefore #. may be used within the feature expression. I find that this
works on my 3600, except that because the 3600 does read the feature in the
keyword package, it is necessary to write Masinter's example as
#+#.USER:(STRING= (SOFTWARE-TYPE) "VMS") whatever
in Zetalisp and as
#+#.(USER:STRING= (USER:SOFTWARE-TYPE) "VMS") whatever
in Common Lisp. (Note that to make this work reliably, one would have to
stipulate that T (or :T) is a feature in every Common Lisp implementation
and that NIL (or :NIL) is a feature in no Common Lisp implementation.
Given this, I find #+#. rather attractive in its ugliness; it shakes you by
the labels and yells "behold, bizarreness beyond belief!")
--Guy
∂17-Jun-85 0912 gls@THINK.ARPA #+who You #-who I #-who can't #+who won't believe this #-who great #+who complete #+who crock #-who feature
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 09:12:32 PDT
Received: by THINK.ARPA with CHAOS id AA07628; Mon, 17 Jun 85 12:06:29 edt
Date: Monday, 17 June 1985, 12:08-EDT
From: The@THINK.ARPA, Great@THINK.ARPA, Quux@THINK.ARPA
Sender: gls@THINK.ARPA
Subject: #+who You #-who I #-who can't #+who won't believe this #-who great #+who complete #+who crock #-who feature
To: common-lisp@sail
Cc: gls@THINK.ARPA
Message-Id: <850617120800.3.GLS@UBALDO.ARPA>
How about a function called READ-IN-ALL-POSSIBLE-WAYS?
It reads in one pseudo-expression and returns an a-list.
A pseudo-expression the amount of text one call to READ
would swallow if both #+ and #- never skipped.
If the pseudo-expression contains n different feature
keywords appearing after #+ and #-, then the resulting
a-list has 2↑n pairs. Each pair is of the form
((AND t1 t2 t3) [sexp])
where each tj is either a feature name fj or else (NOT fj),
and where the sexp may or may not be present. The CAR of
a feature entry therefore describes what features must
obtain in order for the pseudo-expression to be read in
that way. If a sexp is rpesent, that is what would be read.
If the pseudo-expression begins with #+ or #-, then in
some cases it reads an no text at all, and so the sexp is
absent. For example:
(READ-IN-ALL-POSSIBLE-WAYS) #+foo (a b #-bar c)
(((AND FOO BAR) (A B))
((AND FOO (NOT BAR)) (A B C))
((AND (NOT FOO) BAR))
((AND (NOT FOO) (NOT BAR)))
Think any compilers could use this? How about MASTERSCOPE?
--Quux
∂17-Jun-85 0923 smh@mit-eddie.ARPA Re: Features
Received: from MIT-EDDIE.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 09:23:37 PDT
Received: by mit-eddie.ARPA (4.12/4.8) id AA00429; Mon, 17 Jun 85 12:16:32 edt
Date: Mon, 17 Jun 85 12:16:32 edt
From: Steven M. Haflich <smh@mit-eddie.ARPA>
Message-Id: <8506171616.AA00429@mit-eddie.ARPA>
To: common-lisp@su-ai, greek@DEC-HUDSON
Subject: Re: Features
From: greek@DEC-HUDSON
I think we will be making a BIG mistake if we put features in the
keyword package. The entire point of keywords is that they are
completely benign: their value, function, property-list, AND
mere presence or absence from the keyword package is irrelevent.
Different packages can use the same keywords with no harm whatsoever.
Now we want to invent keywords with a boolean "value": whether or
not they are present in the keyword package. Wrong!
It is not proposed that #+FOO just check whether :FOO exists in the
keyword package. Rather, it should check whether that symbol is on the
list which is the value of LISP:*FEATURES*.
I agree it ought never matter whether a symbol does or does not yet
exist in the keyword package, provided one doesn't go looking explicitly
using do-all-symbols, or some such.
∂17-Jun-85 1004 greek@DEC-HUDSON Features.
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 10:03:54 PDT
Date: Mon, 17 Jun 85 13:03:36 EDT
From: greek@DEC-HUDSON
Subject: Features.
To: common-lisp@su-ai
Oh, I wasn't assuming that #+ would just check whether the keyword
exists. Of course it looks in *FEATURES*. My objection is that
we are changing the intention of the keyword package. It is not
the intention of the keyword package to contain information with
any semantic content, just syntactic content.
Upon further consideration, I guess my real objection is against
having package-specific stuff somewhere other than the package itself.
If we said that packages could not add features, that features
pertained only to the Common LISP implementation, then I guess I
wouldn't mind if they were in the keyword package (as opposed to
the LISP package). It's this package-specific stuff in the keyword
package that bothers me.
How about we start over and collect peoples opinions on how to
parameterize the reader and THEN decided how best to implement it?
If that turns out to be #+, fine. If not, we can freeze #+ and
"do it right".
- Paul
∂17-Jun-85 1007 greek@DEC-HUDSON WITH-OPEN-FILE
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 10:05:48 PDT
Date: Mon, 17 Jun 85 13:05:16 EDT
From: greek@DEC-HUDSON
Subject: WITH-OPEN-FILE
To: common-lisp@su-ai
VAX LISP binds the result of the open to the variable. This allows
the body to test it. The code simple ensures that it doesn't try
to close NIL at the end.
- Paul
∂17-Jun-85 1032 DLW@SCRC-QUABBIN.ARPA With-Open-File :if-does-not-exist nil
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 10:31:29 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 172565; Mon 17-Jun-85 13:28:17-EDT
Date: Mon, 17 Jun 85 13:31 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: With-Open-File :if-does-not-exist nil
To: RAM@CMU-CS-C.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: <RAM.12119874583.BABYL@CMU-CS-C.ARPA>
Message-ID: <850617133106.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Reply-To: dlw@SCRC-STONY-BROOK.ARPA
Just change the unwind-protect to check to see if the value of the
stream variable is NIL, and that does nothing if so. The definition
of with-open-file doesn't say anything about not executing the body.
If you use :if-does-not-exist, then it's your responsibility for
dealing with it.
∂17-Jun-85 1033 DLW@SCRC-QUABBIN.ARPA With-Open-File :if-does-not-exist nil
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 10:32:29 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 172566; Mon 17-Jun-85 13:28:31-EDT
Date: Mon, 17 Jun 85 13:31 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: With-Open-File :if-does-not-exist nil
To: RAM@CMU-CS-C.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: <RAM.12119874583.BABYL@CMU-CS-C.ARPA>
Message-ID: <850617133125.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Reply-To: dlw@SCRC-STONY-BROOK.ARPA
Just change the unwind-protect to check to see if the value of the
stream variable is NIL, and to do nothing if so. The definition
of with-open-file doesn't say anything about not executing the body.
If you use :if-does-not-exist, then it's your responsibility for
dealing with it.
∂17-Jun-85 1130 REM@IMSSS Recant: features don't belong in keyword package
Received: from IMSSS by SU-AI with PUP; 17-Jun-85 11:30 PDT
Date: 17 Jun 1985 1127-PDT
From: Rem@IMSSS
Subject: Recant: features don't belong in keyword package
To: greek%DEC-HUDSON@SU-AI
cc: COMMON-LISP@SU-AI
In my comparison of benign characteristics of keywords, I completely forgot
the obvious, that you (greek) pointed out, that the boolean fact of whether
the keyword exists or not isn't important, whereas features are essentially
flags. I therefore amend my proposal. Features should be in their own package
or in some system-standard package such as LISP, except for ad hoc (not yet
registered) features which should temporarily reside in their own private
packages to avoid inadvertant name conflict.
After an ad hoc feature turns into an official (registered) feature, it
moves into the standard package for features, and during the transition
period when a user programmer doesn't know where it might be a boolean
OR can be used to select the two possibilities. Thus first REMTEST3:BIGFLOAT
might be a private feature, then when things are stable the name is submitted
to the registry but there's already some registered feature called exactly
BIGFLOAT so my new feature gets called REMBFLOAT or BFLOAT2 or somesuch,
so we ask programmers to say (OR REMTEST3:BIGFLOAT BFLOAT2) for a while,
then after a reasonable time we change the installed feature name to
be BFLOAT2 which is transparent to any program doing the OR. New programs
written after the transition can of course just use BFLOAT2 without the OR.
-------
∂17-Jun-85 1416 REM@IMSSS Unrecant
Received: from IMSSS by SU-AI with PUP; 17-Jun-85 14:15 PDT
Date: 17 Jun 1985 1413-PDT
From: Rem@IMSSS
Subject: Unrecant
To: smh%mit-eddie@SU-AI
cc: greek%DEC-HUDSON@SU-AI, COMMON-LISP@SU-AI
Aha, I think greek misled us, and smh is right.
The names of the features are interned identifiers (symbols), which
are used only for their data-matching value, i.e. exactly like keywords.
The list which contains all current features, *FEATURES*, is a normal
identifier which shouldn't be in the keyword package, it should be
in LISP or SI or somesuch system package. Now that makes it harder to
handle ad hoc keywords that aren't yet registered and thus might have
conflicting names with features in other user software that may or may not
have been registered. Perhaps the registered features should be keywords
and the unregistered ones should be in private experimental packages, but
all of them should be consed onto the list LISP:*FEATURES* or whatever it is?
Having the unregistered feature names in private packages is wasteful because
they have things like value cells etc. whereas true keywords can actually
be in a special package that doesn't even have hooks for values etc.,
but this inefficient use of fullblown identifiers (symbols) for just
their keyword semantics is temporary until they become registered.
-------
∂17-Jun-85 1459 hplabs!perdue%hplabs.csnet@csnet-relay.arpa Botched mail message
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 14:56:26 PDT
Received: from hplabs by csnet-relay.csnet id ah26751; 17 Jun 85 17:48 EDT
Received: by HP-VENUS id AA15341; Mon, 17 Jun 85 11:20:06 pdt
Message-Id: <8506171820.AA15341@HP-VENUS>
Date: 17-Jun-85 11:05:30
To: postmaster@csnet-relay.arpa
Subject: Botched mail message
From: perdue%hplabs.csnet@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
Mike, here is a copy of one of the messages I got back after
attempting to send mail to Tim Tillson at FSD. Note that the address
shown is "hpfclp!twt@csnet-relay.arpa", but what I actually typed in as
the address was "hpfclp!twt". Thanks for looking into this.
As I mentioned, I have received something around 15 replies of this
general nature.
UUCP X.1
>From uhplabs Mon Jun 17 07:40:58 1985 remote from hpatlS
>From COMSAT@MIT-MC Mon Jun 17 04:11:57 1985 remote from hplabs
Received: by HP-VENUS id AA02358; Mon, 17 Jun 85 04:11:57 pdt
Date: Mon, 17 Jun 85 03:34:37 EDT
From: Communications Satellite <hplabs!COMSAT@MIT-MC>
Received: by HP-VENUS via CSNET; 17 Jun 1985 04:11:54-PDT (Mon)
Received: from su-ai.arpa by csnet-relay.arpa id a022463; 17 Jun 85 3:35 EDT
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 00:33:36 PDT
To: "@SU-AI.ARPA:hplabs!perdue%hplabs.csnet@csnet-relay.arpa"@SU-AI
Via: CSNet; 17 Jun 85 4:11-PDT
Subject: Msg of Monday, 17 June 1985 03:34-EDT
Message-Id: <[MIT-MC].545653.850617>
============ A copy of your message is being returned, because: ============
"PGS@MIT-MC.ARPA" at MIT-MC is an unknown recipient.
============ Failed message follows: ============
Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Jun 85 03:32:52 EST
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 00:22:18 PDT
Received: from hplabs by csnet-relay.csnet id ac22393; 17 Jun 85 3:19 EDT
Received: by HP-VENUS id AA18871; Sun, 16 Jun 85 16:27:57 pdt
Message-Id: <8506162327.AA18871@HP-VENUS>
Date: 16-Jun-85 16:25:39
To: hpfclp!twt@csnet-relay.arpa
Subject: Interesting Common LISP mail
From: perdue%hplabs.csnet@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
Here is an especially interesting piece of mail that was sent out to
the Common LISP distribution list. Note the suggestion of a more or
less official group of implementors of Common LISP for conventional
architectures.
-Cris
UUCP X.1
>From uhplabs Wed Jun 12 03:39:56 1985 remote from hpatlS
>From Moon@stony-brook.scrc.symbolics.com Wed Jun 12 00:21:21 1985 remote from hplabs
Received: by HP-VENUS id AA05084; Wed, 12 Jun 85 00:21:21 pdt
Mail-From: HP-VENUS received 12-Jun-85 00:22:24
Received: by HP-VENUS id AA05040; Wed, 12 Jun 85 00:20:56 pdt
Date: Tue, 11 Jun 85 23:51 EDT
From: "David A. Moon" <hplabs!Moon@stony-brook.scrc.symbolics.com>
Received: by HP-VENUS via CSNET; 12 Jun 1985 00:20:53-PDT (Wed)
Received: from su-ai.arpa by csnet-relay.arpa id a024133; 12 Jun 85 0:00 EDT
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 20:52:13 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252533; Tue 11-Jun-85 23:49:29-EDT
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C>
Via: CSNet; 12 Jun 85 0:20-PDT
Subject: Adjustable and displaced arrays
Cc: common-lisp@SU-AI
In-Reply-To: <FAHLMAN.12118411695.BABYL@CMU-CS-C.ARPA>
Message-Id: <850611235159.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 11 Jun 1985 21:43 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
OK, if we accept Moon's view of the proper semantics for all this, and
if we decide not to outlaw displacing to adjustable arrays, then the
Fortran machines probably have to forego cacheing and let each call to
Aref potentially grovel the headers of both arrays (or a whole chain of
arrays). Maybe that is not so bad, since none of this affects
Simple-Vectors, and they are the only kind of array that really HAS to
be fast.
However, the vendors of non-microcodable machines may feel, with some
justification, that they don't want to slow down ALL references to
non-simple arrays just so that the obscure case of adjusting an array
that is displaced to will work properly. Perhaps the right move is to
unbundle the SIMPLE declaration and allow the user to declare that an
array is NOT-DISPLACED, even if it is not simple in other respects.
Sure. I would think that an appropriate way to proceed would be for the
implementors on non-Lisp machines to get together and agree on a common
set of language extensions to deal with this sort of issue. At a later
time, those extensions can be moved into the standard language, once
they are well-debugged and agreed to be the right thing for all machines
that need them. Until that happens, programs that use the extensions won't
be portable to all implementations (but they will probably be portable to
almost all implementations if the extensions are designed right, e.g. as
ignorable declarations).
-------
-------
∂17-Jun-85 1533 DLW@SCRC-STONY-BROOK.ARPA features
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 15:32:56 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 256071; Mon 17-Jun-85 18:29:15-EDT
Date: Mon, 17 Jun 85 18:32 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: features
To: Fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12119198633.BABYL@CMU-CS-C.ARPA>
Message-ID: <850617183248.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Reply-To: dlw@SCRC-STONY-BROOK.ARPA
I agree with you and Moon. Let them be keywords. The namespace for
packages is already flat; if we are not dealing with conflicting package
names then there is no need to deal with conflicting feature names. The
language is hairy enough as it is.
∂17-Jun-85 1619 J.Dalton%edxa@ucl-cs.ARPA flat name space for pkg names
Received: from UCL-CS.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 16:19:16 PDT
Received: from edxa.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a002496;
17 Jun 85 23:58 BST
From: DALTON FHL (on ERCC DEC-10) <J.Dalton%edxa@ucl-cs.arpa>
Date: Monday, 17-Jun-85 23:25:52-GMT
Message-ID: <132231-763-675@EDXA>
To: common-lisp <common-lisp%su-ai.arpa%cs.ucl.ac.uk@ucl-cs.arpa>,
J.Dalton%edxa@ucl-cs.arpa
Subject: flat name space for pkg names
--------
[This is not a proposal for changing Common Lisp; it is just a request for
information. You may want to reply just to me rather than to the mailing
list.]
We're curently looking into ways of adding "modules" to Prolog, where
modules are just some way of having multiple name spaces. One possible
model for at least some parts of this is Common Lisp packages (packages
rather than Common Lisp modules). But, whenever they are mentioned,
someone always raises the objection that there can be name conflicts
between package names. (Suppose two programs are to be combined and both
have some procedures packaged up in a "graph" package. The "graph" packages
meant to be independent, but they clash.)
My question, then, is this: why was a flat name space for package names
chosen for Common Lisp instead of one that allowed subpackages? And
how are package conflicts of the kind mentioned above meant to be resolved?
Cheers,
Jeff Dalton
AIAI, University of Edinburgh
--------
∂17-Jun-85 2039 FAHLMAN@CMU-CS-C.ARPA flat name space for pkg names
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 20:39:19 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 17 Jun 85 23:39:22-EDT
Date: Mon, 17 Jun 1985 23:39 EDT
Message-ID: <FAHLMAN.12120005614.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: DALTON FHL (on ERCC DEC-10) <J.Dalton%edxa@UCL-CS.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: flat name space for pkg names
In-reply-to: Msg of 17 Jun 1985 19:25-EDT from DALTON FHL (on ERCC DEC-10) <J.Dalton%edxa at ucl-cs.arpa>
Jeff,
At the risk of re-opening some issues that are better left alone, I
will respond in public to your query.
I have no idea what would be an appropriate name-space mechanism for
Prolog, but I don't feel that the single-level namespace of Common Lisp
is a problem. If two packages are to run together in the same system,
they have to agree at *SOME* level of the package system that they are
going to use distinct names. If there's no coordination at all, there's
always the chance of a collision. You can't get rid of this; you can
only bury it deeper.
It would be possible to have a hierarchical package structure (or
nested, if you prefer to look at it that way), analogous in some ways to
hierarchical directories. This makes it possible to have sub-domains of
coordination -- if all files coming from CMU have symbols named things
like CMU:SOME-PACKAGE:SOME-SYMBOL, the CMU people can coordinate package
names among themselves with no fear that MIT people will happen to
choose conflicting names; all we have to agree on is that we use the CMU
super package and MIT uses the MIT super-package. This sort of thing
can be carried on to arbitrary depth.
In Common Lisp we decided that it wasn't worth the added complexity, and
that a single namespace for packages would suffice. I have not yet seen
any reason to regret that decision. If we try to import some new module
(or set of modules) whose choices for package names happen to conflict
with some existing modules, we do minor surgery on one file or the other
to eliminate the conflict. Inelegant, but good enough.
-- Scott
∂18-Jun-85 0636 greek@DEC-HUDSON Features.
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 18 Jun 85 06:35:39 PDT
Date: Tue, 18 Jun 85 09:35:23 EDT
From: greek@DEC-HUDSON
Subject: Features.
To: common-lisp@su-ai
I guess most people think that features should be keywords. I think
this goes against the intended use of keywords, but anyway.
I think the argument that they save space as keywords over regular
symbols is bogus. Are you intending to have thousands of features?
I'm really quite amazed that we've invented packages to hide things,
but people don't want package-specific feature information in the
package.
We HAVE solved the package name conflict to some degree with
RENAME-PACKAGE. Not so for keyword features.
I did a stint as name registrar for VAX/VMS. There are lots and lots
of products and packages for that operating system, and even with
a data base of names and associated information, I had conflicts.
I don't know who is going to be registrar for Common LISP, but I
don't see any reason to make the job harder.
- Paul
∂18-Jun-85 0709 REM@IMSSS No change needed for name-domains in package-name space
Received: from IMSSS by SU-AI with PUP; 18-Jun-85 07:08 PDT
Date: 18 Jun 1985 0707-PDT
From: Rem@IMSSS
Subject: No change needed for name-domains in package-name space
To: COMMON-LISP@SU-AI
If we decide that we want a heirarchy of naming authorities for package
names, analagous to ARPA-Internet host-name domains and to Xanadu/Hypertext
trademark names, it can be implemented as a convention without changing
anything in the CL kernel. You simply hyphenate any package names that
aren't at the top level. Thus you'd have LISP and SI and USER etc. but you'd
have MIT-BIGFLOAT and CMU-SCRIBE and UTAH-PSLCOMPAT and SU-IMSSS-REM-TEMP856A
also. So what's all the fuss about whether or not to have a tree-structured
system of naming authorities when we can do it both ways at the same time
without changing any CL implementation?
Probably we'd let any name be used during debugging, but when exporting a
package to another site we'd want the name of the package to be fully
qualified to avoid any chance of naming conflict later. Thus TEMP856A
might be my first temporary package this month, until I share it with
somebody at H/P at which point I have to change the name to the fully
qualified name given in the previous paragraph.
-------
∂18-Jun-85 0733 FAHLMAN@CMU-CS-C.ARPA No change needed for name-domains in package-name space
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 Jun 85 07:33:15 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 18 Jun 85 10:33:20-EDT
Date: Tue, 18 Jun 1985 10:33 EDT
Message-ID: <FAHLMAN.12120124657.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Rem%imss@SU-SCORE.ARPA
Cc: COMMON-LISP@SU-AI.ARPA
Subject: No change needed for name-domains in package-name space
The point of a hierarchical package space, instead of simply
using hierarchical conventions for the names themselves, is that if I
already have a package named FOO (a shorthand, perhaps, for
PACKAGE-NAME-ROOT:FOO) and I get a distinct package named FOO, I can
with proper care make the latter into PACKAGE-ROOT:IMPORTS:FOO just by
loading it right, and not by going in and editing anythign within the
package. Again, the analogy to a tree-structured directory is useful in
understanding this: in most decent operating systems I can make
/usr/mystuff be the default, and then operate as though there were no
other directories around; I never have to worry about stuff in
/usr/yourstuff unless I explicitly ask for that.
Please note that I am NOT advocating any changes to Common Lisp here. A
tree structured package system would have both benefits and costs (in
greater complexity), and I like the tradeoff we currently hae in the
language.
-- Scott
∂18-Jun-85 0900 DCP@SCRC-QUABBIN.ARPA Features
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 18 Jun 85 08:59:50 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 172970; Tue 18-Jun-85 11:57:56-EDT
Date: Tue, 18 Jun 85 11:53 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Features
To: greek@DEC-HUDSON.ARPA, Guy Steele <gls@THINK.ARPA>, Quux@THINK.ARPA,
Steven M. Haflich <smh@MIT-EDDIE.ARPA>, dlw@SCRC-STONY-BROOK.ARPA,
common-lisp@SU-AI.ARPA, Masinter.pa@XEROX.ARPA,
greek%DEC-HUDSON@SU-AI.ARPA, smh%mit-eddie@SU-AI.ARPA,
Fahlman@CMU-CS-C.ARPA
In-Reply-To: The message of 17 Jun 85 11:13-EDT from greek@DEC-HUDSON.ARPA,
<850617115428.2.GLS@UBALDO.ARPA>,
<850617120800.3.GLS@UBALDO.ARPA>,
<8506171616.AA00429@mit-eddie.ARPA>,
The message of 17 Jun 85 13:03-EDT from greek@DEC-HUDSON.ARPA,
The message of 17 Jun 85 14:27-EDT from Rem@IMSSS,
The message of 17 Jun 85 17:13-EDT from Rem@IMSSS,
<850617183248.1.DLW@CHICOPEE.SCRC.Symbolics.COM>,
The message of 18 Jun 85 09:35-EDT from greek@DEC-HUDSON.ARPA
Message-ID: <850618115336.3.NFEP@NEPONSET.SCRC.Symbolics.COM>
Three opinions on this subject:
(1) If we are going to order things by kludginess, I think #, is
kludgier than #., and that #. is kludgier than #+.
(2) I don't think
#+#.pred form
should work, partially because this is combining two evils at the
same time (as opposed to #+pred #.form2 which is two evils at
different times!)
(3) I'm not vehement about this one, but I think features should be in
the keyword package. This allows a relatively simple impmentation
of #+ in that it simply binds *package* to the keyword package,
turns off #. (ours doesn't right now), does a READ and parses the
result. This leads to a slight inconsistency in our implementation:
#+3600 causes 3600 (in base 10, because #+ also binds *read-base* to
10) and this simply causes 3600 to be read in as an integer. Since
our test on *features* is EQ (should be EQL), this still works.
Independent of the above, I think the following needs to be made clear
to implementors (which probably means it has to go into CLtL, even
though that isn't an implementors guide). The conditional read
construct (currently it is #+/#-) must turn of package errors and
probably #. and #, while reading forms for effect. Example:
(defun frob-net ()
#+Symbolics (neti:frob-net)
#+Spice (spice-network:frob-net)
#-(or Symbolics Spice) (error "I see no network here."))
I think it is important for portability to have a read time conditional.
How about this proposal (this is very serious and not intended to be a
flame): Features are in the keyword package. This means they need to
be registered because the keyword package is flat. Registered
trademarks can appear as-is, E.g., #+3600, #+Symbolics, #+LMI, etc.
(Maybe this should extend to major organizations (maybe they're already
registered?)? #+MIT, etc.) Another set of keywords is globally agreed
upon by this group, or by the yellow pages group, e.g., #+Flavors.
Non-registered keywords must be prefaced with the name of the group that
supports the implementation, e.g., #+Symbolics-Rel-6, #+MIT-System-99,
etc.
∂19-Jun-85 0716 greek@DEC-HUDSON Common LISP Registrar
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 19 Jun 85 07:12:52 PDT
Date: Wed, 19 Jun 85 10:12:35 EDT
From: greek@DEC-HUDSON
Subject: Common LISP Registrar
To: common-lisp@su-ai
I hereby volunteer to be the Common LISP registrar. This would involve
registering package names, features, and anything else we think is
necessary.
- Paul
∂20-Jun-85 0645 greek@DEC-HUDSON Common LISP Registrar
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 20 Jun 85 06:45:24 PDT
Date: Thu, 20 Jun 85 09:44:55 EDT
From: greek@DEC-HUDSON
Subject: Common LISP Registrar
To: common-lisp@su-ai
Since I haven't gotten any response to my offer to be Common LISP
registrar, I assume people are either vastly disinterested or not
sure what I mean. Is there enough interest that I should write up
a little proposal and send it around? The proposal would describe
what registration meant and suggest a few policies therefor.
- Paul
∂20-Jun-85 0709 DCP@SCRC-STONY-BROOK.ARPA Common LISP Registrar
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Jun 85 07:05:56 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 259196; Thu 20-Jun-85 09:57:55-EDT
Date: Thu, 20 Jun 85 09:58 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Common LISP Registrar
To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 20 Jun 85 09:44-EDT from greek@DEC-HUDSON
Message-ID: <850620095809.9.NFEP@NEPONSET.SCRC.Symbolics.COM>
Date: Thu, 20 Jun 85 09:44:55 EDT
From: greek@DEC-HUDSON
Since I haven't gotten any response to my offer to be Common LISP
registrar, I assume people are either vastly disinterested or not
sure what I mean. Is there enough interest that I should write up
a little proposal and send it around? The proposal would describe
what registration meant and suggest a few policies therefor.
If there is going to be the possibility of global name conflicts, at
least one registrar is needed. Are you volunteering to be the N
registrars for the N possible conflicts? Some subset of N? Or
specifically the case that seems to have brought this up: The registry
of *FEATURES*?
∂20-Jun-85 0832 FAHLMAN@CMU-CS-C.ARPA Common LISP Registrar
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Jun 85 08:32:17 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 20 Jun 85 11:31:23-EDT
Date: Thu, 20 Jun 1985 11:31 EDT
Message-ID: <FAHLMAN.12120659519.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: greek@DEC-HUDSON.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Common LISP Registrar
In-reply-to: Msg of 20 Jun 1985 09:44-EDT from greek at DEC-HUDSON
I think that the lack of response to your offer to be the Common Lisp
name registrar is because the problem that that would solve doesn't
exist yet. So far, we've had no trouble at CMU with conflicting package
names in our system or in our code libarary, and we don't use the #+
stuff at all. If we wanted to import something into our library from
outside and there was a name conflict, it seems to me that the quickest
and easiest solution would be for the library maintainers to fix the
problem in some locally appropriate way. Right now, I think that
name-conflict resolution is just a natural part of library maintenance.
I suppose that someday there will be a lot of commerce in Common Lisp
software, and it will benefit the customers that the various big AI
packages and various public and proprietary libraries all respect one
another's conventions. In that future time, it will be necessary to
have some official registrar. It will also be important that there be
some agreed-upon mechanism for resolving disputes over these names. Do
we give a nice package/feature name like GRAPHICS to the first outfit
that asks for it (setting off a gold rush to grab all the good names for
future use, much as some companies are now trying to trademark every
English word and a lot of otherwise-useful numbers), or do we try to
assign a name like GRAPHICS to whatever is the most widely used graphics
package around at the time, or do we say that only names like
DEC-GRAPHICS will be registered if the root name is too generic?
-- Scott
∂20-Jun-85 1107 RWK@SCRC-STONY-BROOK.ARPA Common LISP Registrar
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Jun 85 11:07:20 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 259462; Thu 20-Jun-85 13:05:40-EDT
Date: Thu, 20 Jun 85 13:06 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Common LISP Registrar
To: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
cc: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <850620095809.9.NFEP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <850620130623.2.RWK@CROW.SCRC.Symbolics.COM>
Date: Thu, 20 Jun 85 09:58 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Date: Thu, 20 Jun 85 09:44:55 EDT
From: greek@DEC-HUDSON
Since I haven't gotten any response to my offer to be Common LISP
registrar, I assume people are either vastly disinterested or not
sure what I mean. Is there enough interest that I should write up
a little proposal and send it around? The proposal would describe
what registration meant and suggest a few policies therefor.
If there is going to be the possibility of global name conflicts, at
least one registrar is needed. Are you volunteering to be the N
registrars for the N possible conflicts? Some subset of N? Or
specifically the case that seems to have brought this up: The registry
of *FEATURES*?
Humurous (?) suggestion: Be the Registrar of Common Lisp Naming Registrars.
More seriously, I think it's important that we consider registries as
a (mostly compatible) change in the semantics of the language.
Don't take that to mean I think it's a bad idea, however. If we're going
to do it, we should do it right, and document it, consider its impact, and
possibly make other changes in light of that. We may wish to provide ways
that users can choose names guarenteed not to conflict with any registered
name. For example #+FOO vs #+PRIVATE:FOO. (I don't know if this case
example solves a real problem).
I don't think this is hard or much work, so long as we recognize
that it IS a change.
∂20-Jun-85 1202 OLDMAN@USC-ISI.ARPA make-string-output-stream
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 20 Jun 85 12:02:28 PDT
Date: 20 Jun 1985 15:01-EDT
Sender: OLDMAN@USC-ISI.ARPA
Subject: make-string-output-stream
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]20-Jun-85 15:01:13.OLDMAN>
Why doesn't make-string-output-stream accept an optional string
(that has a fill pointer)? Format and with-output-to-string
which presumably use that function accept such a destination
string.
--Dan Oldman
∂20-Jun-85 1521 Moon@SCRC-STONY-BROOK.ARPA What package are feature names resident in?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Jun 85 15:21:05 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 259808; Thu 20-Jun-85 16:58:33-EDT
Date: Thu, 20 Jun 85 16:58 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: What package are feature names resident in?
To: Common-Lisp@SU-AI.ARPA
References: <850613224203.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <850620165838.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I'd like to revise my proposal to be that the "feature expression" after a
#+ or #- is read in the keyword package if no explicit package prefix
appears in it, but it is legal to use an explicit package prefix. I also
propose that features defined in the Common Lisp manual be in the keyword
package, and "public" features (such as those of a particular implementation)
be in the keyword package, by convention. "Private" features can be qualified
with a package name when that convention seems appropriate. I also endorse
KMP's proposal that package failure while reading a feature name is
equivalent to nonpresence of that feature, rather than being an error.
Thus (list 1 #+(not nosuchpackage:quux) 2 3) evaluates to a list of 3
elements in most circumstances.
∂20-Jun-85 1752 FAHLMAN@CMU-CS-C.ARPA What package are feature names resident in?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Jun 85 17:52:40 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 20 Jun 85 20:51:59-EDT
Date: Thu, 20 Jun 1985 20:51 EDT
Message-ID: <FAHLMAN.12120761580.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: What package are feature names resident in?
In-reply-to: Msg of 20 Jun 1985 16:58-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Moon's revised proposal sounds good to me.
-- Scott
∂21-Jun-85 0609 greek@DEC-HUDSON Features & Common LISP Registrar
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 21 Jun 85 06:08:45 PDT
Date: Fri, 21 Jun 85 09:08:17 EDT
From: greek@DEC-HUDSON
Subject: Features & Common LISP Registrar
To: common-lisp@su-ai
Moon's proposal sounds good to me (now that I've stopped yelling
about features in the keyword package). Do we really need to say
that errors while reading the feature are equivalent to it not
being there? Without an error handling mechanism in Common LISP,
that may be tough to implement for some people.
Well, thank y'all for the response to my registrar proposal. It seems
worth it for me to take some time and write up a short proposal.
You'll get it by the end of the day.
- Paul
∂21-Jun-85 0807 greek@DEC-HUDSON Proposal for Common LISP Registrar
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 21 Jun 85 08:04:37 PDT
Date: Fri, 21 Jun 85 11:04:07 EDT
From: greek@DEC-HUDSON
Subject: Proposal for Common LISP Registrar
To: common-lisp@su-ai
PROPOSAL FOR COMMON LISP REGISTRY
Purpose
-------
The purpose of the Common LISP Registry is to prevent or resolve
conflicts in software written for Common LISP implementations.
These conflicts can arise in the following areas:
o Feature names. We must agree on those features which will be
in a flat name space (the keyword package, if we adopt the
latest proposal). Such features include implementation subsystems,
company names, operating system names, etc. Package-specific
features will be in the packages themselves (again, if we agree).
o Package names. The package name space is flat, so each and every
package that a user might need should have a unique name.
o Extensions. The Registry could also maintain a central collection
of Common LISP extensions, thus increasing the probability that
similar extensions are implemented in a consistent fashion. Such
extensions might include additional sharp-sign reader macros,
additional format directives, use of numeric extension characters,
additional character bits, etc. This tends to be controversial,
since it's akin to proposing additions to the language, so maybe
it's not time for this yet. Comments?
o Surely I forget something.
Feature Names
-------------
The Registry would be responsible for keeping track of those feature
names which reside in a flat name space. The conventions would be as
follows (exact names to be determined):
o Feature names for LISP dialects are such things as COMMON-LISP,
MACLISP, FRANZ-LISP, etc. We should agree on these so that people
can write dialect-independent code if possible. We already have
some Common LISP implementations using the feature COMMON-LISP and
others using just COMMON.
o Feature names for Common LISP subsystems are such things as
COMPILER, EDITOR, TRACER, FLAVORS, etc. These would be generic
names that indicate that some (hopefully standard) such subsystem
exists in this implementation.
o Feature names for companies are such things as DEC, SYMBOLICS, TI,
etc. These names can correspond to trademarks.
o Feature names for computers are such things as VAX, DECSYSTEM-20,
SYMBOLICS-3600, EXPLORER, etc. These names can correspond to
trademarks.
o Feature names for operating systems are such things as VMS, UNIX,
MSDOS, etc. Some of these names can correspond to trademarks.
o Feature names for specific Common LISP implementations are such
things as VAX-LISP, SPICE-LISP, etc.
Note that the last four items are redundant with some of the functions
in Section 25.4.2 of CLtL. This is unfortunate, but the functions are
meant to be descriptive to people, while the features are meant to
be tested by code.
I believe that package-specific features should reside in the package,
but this is currently under debate.
An implementation would also be free to add any features in the flat
name space, so long as they were prefixed with registered features
belonging to that implementation (e.g., VAX-LISP-MUMBLE is registered
by virtue of VAX-LISP being registered).
Package Names
-------------
The Registry would be responsible for keeping track of package
names. The conventions would be as follows:
o The following package names are currently standard: LISP, USER,
KEYWORD, SYSTEM (SYS).
o Any package names which are prefixed with SYSTEM- or SYS- are
considered to be implementation-specific and are automatically
registered.
o Another set of generic package names will be preregistered for
Common LISP subsystems. These are to be determined, but an
example is EDITOR. This name is reserved for the editor in
any given implementation. A goal is that these names coincide
with the corresponding feature names.
Note that this convention precludes anyone from creating a
fancy new Common LISP editor and selling it under the name
of EDITOR (or DEBUGGER or FLAVORS or GRAPHICS or ...).
o All other package names must be registered, most importantly
those which are assigned to a product to be sold.
o It will be possible to register a package prefix. For example,
the Acme Artificial Intelligence Corp. registers GAMBLING-EXPERT-*
for a set of gambling expert systems. The star is a wildcard,
meaning that all names beginning with GAMBLING-EXPERT- are
registered.
An implementation would also be free to create additional package names
as long as they were prefixed with a registered feature belonging
to that implementation (e.g., VAX-PACKAGE3 is registered by virtue
of VAX being a registered feature). This would, in fact, be the
recommended way for an organization to make up package names for
separate products.
Other Conventions
-----------------
All registration would be on a first-come-first-served basis. The
Registrar has the right, within reason, to refuse to register a name
which is too generic (e.g., ENGINEERING), to short (e.g., A*), likely
to conflict with future Common LISP extensions (e.g., GKS), or what
have you. In such cases, the reason will always be given.
All online correspondence with the registrar will be via the Arpanet to
an account with a name such as COMMON-LISP-REGISTRAR. Registration can
also be done in writing.
The Registration List
---------------------
A complete registration list would be published from time to time and
distributed to the Common LISP mailing list. Hard copy would also be
available upon request.
Many new packages may be considered proprietary by the developing
organization. I would certainly make a provision for this and not
publish such packages. However, since I work for Digital it may be
that the organization does not even want me to know about the package.
That is why I have provided for automatic registration of names
prefixed with a registered feature name.
∂21-Jun-85 1656 FAHLMAN@CMU-CS-C.ARPA Proposal for Common LISP Registrar
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Jun 85 16:55:57 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 21 Jun 85 19:55:20-EDT
Date: Fri, 21 Jun 1985 19:55 EDT
Message-ID: <FAHLMAN.12121013413.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: greek@DEC-HUDSON.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Proposal for Common LISP Registrar
In-reply-to: Msg of 21 Jun 1985 11:04-EDT from greek at DEC-HUDSON
This looks very good to me. Paul has worked out nice solutions to
several of the problems I raised in my earlier message.
On the issue of registering implementation-specific extensions, a few
comments:
It is essential that any implementation group be free to extend their
own Common Lisp in any compatible way, without asking anyone's
permission. Given that, there is considerable benefit to having these
groups publicize the extensions they have decided to make, so that other
groups making similar extension can do this in a way that is not
gratuitously incompatible. The goal of universal compatibility is even
better served if the group making the extension is willing to make the
code available to others. I'm sure that some companies and universities
will be more forthcoming about this than others -- there's a tradeoff
between compatibility with competitors and the possibility of gaining an
advantage by keeping such information private.
In any event, "registering" this information is a rather more complex
business than simply registering package names and keywords. Perhaps
the right mechanism is for companies to be encouraged to make their red
pages available to other implementation groups through some sort of
clearinghouse. A central registry could keep a list of groups willing
to supply such info, the address to write to when you want such info,
and perhaps an index of what extensions are included in each company's
stuff.
-- Scott
∂23-Jun-85 1502 JLW What package are feature names resident in?
To: moon@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
In-reply-to: your message of 20-Jun-85 16:58 EDT
Your most current proposal is exactly what I had been hoping for
when first bringing this problem up; namely
1) features are symbols, and the basic "featurep" amounts to
a memq on the *features* list; and
2) *package* is temporarily rebound to the keyword package while
reading in the feature form, so that the default case is to look
for symbols on the keyword package.
This solution permits random, or non-keyword, features to exist, but
puts the burden on the instigator and user of such random features
to prefix them by their package name. Contrast this with the only
secure way to use a feature name that is immune to incidental
shadowings -- every user would be forced to package-qualify their
feature names. Better to not burden the common case user.
Two other items I hadn't anticipated seem to have come up
1) Non-existent package qualifiers should be interpeted, in this
context, to be missing features [as opposed to being an error]
2) The user of #. will have to be aware of the context change,
or else #. will have to be outlawed in the #+ context.
I have no particlar feelings on (2) one way or the other, but
I do feel rather strongly that *whenever* a programmer has to
resort to the use of #., it is an indication of a shortcoming
in the defined external syntax. If a reasonable programmer can't
find an alternative for his usages of #., then the Common Lisp
community should have an action/discussion item on its agenda.
Stress "reasonable".
-- JonL --
∂23-Jun-85 1519 JLW Need for #+ and #-
To: common-lisp@SU-AI.ARPA
Apologies if I'm addressing a non-problem here, but a quick scan of the CL
main for the past two weeks there seemed to show an undercurrent of question
about the need for #+ and #-, the counter proposal being to do everything
by means of eval time macros.
A common case wherein I used reader conditionalization while at MIT was
in the building and maintenance of several data files. These files had
#+ and #- in them, and I wouldn't seriously contemplate writing a post
processor for all data read in, simply in order to avoid using #+.
One may argue that certain pieces of lisp programs that have reader
conditionalizations in them would have been in better style had they
used some eval time macro [no need to bring in the compiler here --
I assume that (cond (t ...)) would be optimized, but that doesn't
really matter]. On the other hand, in some cases, the #+ construct makes
for much more succinct and readable code; compare a #+ in a bound
variable list with the eval-time macro that must construct up such
a defun in the absence of reader conditionals.
-- JonL --
∂24-Jun-85 0643 greek@DEC-HUDSON Common LISP Registry
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 24 Jun 85 06:42:41 PDT
Date: Mon, 24 Jun 85 09:42:09 EDT
From: greek@DEC-HUDSON
Subject: Common LISP Registry
To: common-lisp@su-ai
Well, I seem to be receiving a positive response to my proposal for
the Common LISP Registry. I hope for some more responses, particularly
if anyone sees problems with my proposal.
I'll think about what Scott said concerning registering Common LISP
extensions and add something to a second round proposal. I had intended
to include a contact address in every registration anyway.
Once I've incorporated all comments, I'll send out a second round
proposal, including a new section on the registration procedure itself.
After that, if there are no objections, I'll declare the registry
open?
Please, let me know what you think.
- Paul
∂24-Jun-85 1929 STEINER@RU-BLUE.ARPA Dribble and *error-output*
Received: from RU-BLUE.ARPA by SU-AI.ARPA with TCP; 24 Jun 85 19:28:59 PDT
Date: 24 Jun 85 22:28:36 EDT
From: Dave <Steiner@RU-BLUE.ARPA>
Subject: Dribble and *error-output*
To: common-lisp@SU-AI.ARPA
Reply-To: Steiner@Rutgers
Currently the Slisp implementation of Dribble makes a broadcast
stream of *standard-output* and the dribble file. If you get an
error while doing this, it doesn't show up in the dribble file.
Wouldn't it make sense to also have *error-output* be one of the
broadcast streams?
ds
uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner
arpa: Steiner@RUTGERS
-------
∂24-Jun-85 2028 FAHLMAN@CMU-CS-C.ARPA Dribble and *error-output*
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Jun 85 20:27:49 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 24 Jun 85 23:26:44-EDT
Date: Mon, 24 Jun 1985 23:26 EDT
Message-ID: <FAHLMAN.12121838328.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Steiner@RUTGERS.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Dribble and *error-output*
The SLISP version of dribble should not be taken as definitive. Dribble
exists here only because the manual says we have to have one. Everyone
at CMU uses an editor top-level, so if we want a console transcript we
just write out the editor buffer.
-- Scott
∂25-Jun-85 0511 RAM@CMU-CS-C.ARPA Dribble and *error-output*
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 25 Jun 85 05:10:53 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Tue 25 Jun 85 08:10:45-EDT
Date: Tue, 25 Jun 1985 08:10 EDT
Message-ID: <RAM.12121933724.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Steiner@RUTGERS.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Dribble and *error-output*
In-reply-to: Msg of 24 Jun 1985 22:28-EDT from Dave <Steiner at RU-BLUE.ARPA>
Not any more, it doesn't. It redirects *terminal-io*. Perhaps
you have some old version. We lost our original version which was
rewritten way back in the beginning, so I rewrote it as the following
function:
(defun dribble (&optional pathname &key (if-exists :append)
(if pathname
(with-open-file (f pathname :if-exists if-exists
:if-does-not-exist :create)
(catch 'dribble-punt
(let ((*terminal-io*
(make-two-way-stream
(make-echo-stream *terminal-io* f)
(make-broadcast-stream *terminal-io* f))))
(%top-level))))
(throw 'dribble-punt nil)))
This is in misc.slisp
Rob
∂25-Jun-85 1325 hplabs!Snyder%hplabs.csnet@csnet-relay.arpa feature names
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 25 Jun 85 13:25:08 PDT
Received: from hplabs by csnet-relay.csnet id cx00847; 25 Jun 85 16:04 EDT
Received: by HP-VENUS id AA25905; Tue, 25 Jun 85 10:58:48 pdt
Message-Id: <8506251758.AA25905@HP-VENUS>
Date: 25-Jun-85 09:57:28
To: Common-Lisp@su-ai.ARPA
Subject: feature names
From: Snyder%hplabs.csnet@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
If we agree that feature names are to be read in the keyword package,
then I claim there is no advantage to allowing package prefixes to
appear in feature names. In particular, if you have to write MIT:FOOBAR
to name your feature, why not write MIT-FOOBAR instead? What makes
the package system "better" than long names is the ability to be
"in" a particular package, so you don't have to write the package name
on each symbol. If feature names are always read "in" the keyword
package, then this advantage disappears. The disadvantage of allowing
package prefixes in feature names is this business of supressing
package system errors.
Alan
-------
∂26-Jun-85 0940 Moon@SCRC-STONY-BROOK.ARPA char-equal of control characters
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Jun 85 09:40:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 263544; Wed 26-Jun-85 12:35:49-EDT
Date: Wed, 26 Jun 85 12:39 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: char-equal of control characters
To: Common-Lisp@SU-AI.ARPA
Message-ID: <850626123932.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
We're encountering continuing difficulties caused by the fact that
CHAR-EQUAL (and the related character and string functions) ignores
differences in the bits attribute, so that (CHAR-EQUAL #\A #\Control-A)
is true. Does anyone remember the motivation for specifying CHAR-EQUAL
this way? It's not set forth in the Common Lisp manual. I went through
all my old draft manuals, back to to Colander edition of 29 July 1982,
but found no illumination.
Since graphic-char-p, alpha-char-p, upper-case-p, and digit-char-p
are influenced by the bits attribute of a character, it appears that
two characters with different bits attributes are considered to be
essentially different, in the same way that pea and pi are essentially
different (see the example under CHAR-EQUAL in the manual).
I'm not proposing to change anything at this time, but I'd like to
understand the motivation. Can the other designers of Common Lisp
comment on this? Do any of the other implementors of Common Lisp
have relevant experience to offer?
∂26-Jun-85 1527 Fischer.pa@Xerox.ARPA Adjustable and displaced arrays (summary)
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 26 Jun 85 15:26:44 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 26 JUN 85 15:26:02 PDT
Date: 26 Jun 85 15:25 PDT
From: Fischer.pa@Xerox.ARPA
Subject: Adjustable and displaced arrays (summary)
To: Common-Lisp@SU-AI.arpa
Message-ID: <850626-152602-1271@Xerox>
Here is "my understanding" of adjustable and displaced arrays.
This is an "unproofed by the other participants" summary of a discussion
between: Moon@STONY-BROOK.SCRC.Symbolics.COM, fischer.pa,
Fahlman@CMU-CS-C, Greek@DEC-HUDSON, RAM@CMU-CS-C, GSB@MIT-MC
A simple implementation example of displaced arrays: a displaced array
keeps a pointer to the actual array that it is displaced to. Accesses
to such a displaced array must look down the chain of displacements to
make a reference. It is important that the behavior of this technique
be preserved. It becomes critical when, for instance, an array
somewhere in the chain of displacements is handed to adjust-array and
given a new displacement. Accesses must then follow the new chain.
Your mileage may vary, eg you can optimize this any way you please, most
commonly by encaching information in the array "header" about the
ultimate address and offset of the block of data being referenced. A
scheme to update the encached information is then called for (possibly
for the whole chain of displaced arrays).
adjust-array can alter the dimensionality and contents (or displacement)
of an array. It doesn't move elements around to preserve order. It
only copies elements if the array they are part of enlarges or shrinks*.
Here is an outline of the cases adjust-array handles:
If a displacement is given as an argument
then
set dimensions
set displacement
else if the old array was displaced
then
copy the elements (shrink, enlarge or same size**)
set new dimensions
else if new dimensions have same linear size as old
then
simply set dimensions
else
; new dimensions with different linear size
copy elements to new size block.
Bear in mind that initial-element, initial-contents, and displaced-to,
are mutually exclusive. Completely new contents may be specified by
initial-contents. Gaps in a newly enlarged array may be initialized
with initial-element.
[*Note: CLtL specifically does not specify when an error should be
signalled if adjusting an array causes another array displaced to it to
have invalid linear size. This could be done at adjust-array time or
aref time. Seems to be your choice.]
[**Note: this interpretation of the case where a displaced array loses
its displacement is made arbitrarily. It is unclear from the text of
CLtL whether the elements should be copied into a new block to remove
the old displacement, or whether a blank storage block should be
created. The former seems somewhat more reasonable.]
(ron)
∂26-Jun-85 1800 FAHLMAN@CMU-CS-C.ARPA char-equal of control characters
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Jun 85 18:00:14 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 26 Jun 85 20:59:57-EDT
Date: Wed, 26 Jun 1985 20:59 EDT
Message-ID: <FAHLMAN.12122335888.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: char-equal of control characters
In-reply-to: Msg of 26 Jun 1985 12:39-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Now that you mention it, this business about CHAR-EQUAL ignoring
differences in the bits attributes looks like a pure mistake to me. I
don't remember any discussion of this -- it probably just sounded
halfway plausible and slipped by us all at the time. (Then again, I
might be misremembering. I've got no easy way to search the archives.)
If we think of the bits attribute as encoding things like control and
meta -- funny shift modifiers that really only make sense in keystrokes
coming in -- I can't think of very many situations in which we would
want to consider #\control-A as being in an equivalence class with #\A.
It certainly is not a situation that parallels the close relationship
between #\A and #\a.
Unless someone thinks of a good reason why CHAR-EQUAL ought to be the
way the manual says it is, maybe we should consider changing CHAR-EQUAL
to take differing bits into account.
The next time we design a new Lisp, we should separate the concept of
characters (which might or might not want to have fonts attached) and
input-keystrokes, which would be some implementation-dependent
representation of anything that might come in from keyboard land,
including combinations of shift bits. It was a mistake to muddle these
two ideas together, but it is too late to change that now.
-- Scott
∂26-Jun-85 1942 Moon@SCRC-STONY-BROOK.ARPA char-equal of control characters
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Jun 85 19:42:08 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 264017; Wed 26-Jun-85 22:37:20-EDT
Date: Wed, 26 Jun 85 22:41 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: char-equal of control characters
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12122335888.BABYL@CMU-CS-C.ARPA>
Message-ID: <850626224129.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 26 Jun 1985 20:59 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
The next time we design a new Lisp, we should separate the concept of
characters (which might or might not want to have fonts attached) and
input-keystrokes, which would be some implementation-dependent
representation of anything that might come in from keyboard land,
including combinations of shift bits. It was a mistake to muddle these
two ideas together, but it is too late to change that now.
I'm not sure I agree with that, since that is what we did in the Lisp machine
world originally (before character objects) and it has been a continuing source
of grief.
∂26-Jun-85 1959 FAHLMAN@CMU-CS-C.ARPA char-equal of control characters
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Jun 85 19:59:03 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 26 Jun 85 22:59:00-EDT
Date: Wed, 26 Jun 1985 22:58 EDT
Message-ID: <FAHLMAN.12122357567.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: char-equal of control characters
In-reply-to: Msg of 26 Jun 1985 22:41-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
The next time we design a new Lisp, we should separate the concept of
characters (which might or might not want to have fonts attached) and
input-keystrokes, which would be some implementation-dependent
representation of anything that might come in from keyboard land,
including combinations of shift bits. It was a mistake to muddle these
two ideas together, but it is too late to change that now.
I'm not sure I agree with that, since that is what we did in the Lisp machine
world originally (before character objects) and it has been a continuing source
of grief.
Well, the grief might be due directly to the separation of keystrokes
and characters, or it might be due to interaction with some other
problems in the way the Lisp Machine deals with characters. We would
have to isolate the various issues involved before deciding. In any
event, "the next time we design a new Lisp" will (for me) not be in my
current incarnation, and probably not the next one since I am scheduled
to come back as some sort of mollusc next time around, and few of them
design programming languages. (Please, no puns about shell scripts...)
-- Scott
∂26-Jun-85 2009 Moon@SCRC-STONY-BROOK.ARPA Adjustable and displaced arrays (summary)
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Jun 85 20:08:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 264033; Wed 26-Jun-85 23:03:35-EDT
Date: Wed, 26 Jun 85 23:07 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Adjustable and displaced arrays (summary)
To: Common-Lisp@SU-AI.ARPA
References: <850626-152602-1271@Xerox>
Message-ID: <850626230737.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Fischer's message agrees with my understanding of the situation.
∂27-Jun-85 0653 greek@DEC-HUDSON Comments on Array Summary.
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 27 Jun 85 06:53:26 PDT
Date: Thu, 27 Jun 85 09:52:56 EDT
From: greek@DEC-HUDSON
Subject: Comments on Array Summary.
To: common-lisp@su-ai
After reading Ron's summary, here are my comments:
Case 1.
OK.
Case 2.
I'm not sure I agree that copying the elements when undisplacing
an array is correct. Hey, if the user doesn't want to have one
array look at the same elements as another, then it shouldn't,
either by sharing or copying. You want to copy an array, then
copy it explicitly. Of course, we don't have COPY-ARRAY, but I'd
sure hate to see people copy arrays by displacing to them and then
undisplacing! Blech.
I'd be perfectly happy if it was an error to undisplace an array;
if not, then it shouldn't copy and we should require an :INITIAL-ELEMENT
or :INITIAL-CONTENTS option.
Case 3.
I presume :INITIAL-ELEMENT or :INITIAL-CONTENTS is allowed in this
case to reinitialize the array?
Case 4.
I presume here that you mean "copy if necessary"? In particular, if
the new linear size is smaller than the old, many implementations
can just change the array dimensions and not touch the data itself.
Of course, doing so may prevent lots of data from ever being GCed.
Again, I presume :INITIAL-ELEMENT or :INITIAL-CONTENTS are OK.
General.
Just exactly what does :ELEMENT-TYPE do in each situation?
Just exactly what happens to a fill pointer in each situation?
∂28-Jun-85 1037 KMP@SCRC-STONY-BROOK.ARPA feature names
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Jun 85 08:42:03 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 265138; Fri 28-Jun-85 11:36:59-EDT
Date: Fri, 28 Jun 85 11:41 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: feature names
To: Snyder%hplabs.csnet@CSNET-RELAY.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <8506251758.AA25905@HP-VENUS>
Message-ID: <850628114121.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Comment: Remailed at SU-AI after delay caused by dist list error.
Date: 25-Jun-85 09:57:28
From: Snyder%hplabs.csnet@csnet-relay.arpa
If we agree that feature names are to be read in the keyword package,
then I claim there is no advantage to allowing package prefixes to
appear in feature names. In particular, if you have to write MIT:FOOBAR
to name your feature, why not write MIT-FOOBAR instead? What makes
the package system "better" than long names is the ability to be
"in" a particular package, so you don't have to write the package name
on each symbol. If feature names are always read "in" the keyword
package, then this advantage disappears. The disadvantage of allowing
package prefixes in feature names is this business of supressing
package system errors.
Recall that #+ and #- are not the only things which hack features. Admittedly
in light of that limited context it seems silly, but there is a bigger issue of
what happens to other programs that which to probe the existence of features.
eg, my FEATURE-CASE primitive.
Besides, you already have to be able to suppress package system errors somehow
inside other contexts for the sake of *READ-SUPPRESS*. I'd be willing to go so
far as to say NIL should never be a valid feature so that package errors could
be handled similarly in this context, returning NIL which would be the equivalent
of a non-existent feature...
∂28-Jun-85 1415 Fischer.pa@Xerox.ARPA Re: Comments on Array Summary.
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 28 Jun 85 14:15:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 28 JUN 85 14:13:58 PDT
Date: 28 Jun 85 14:12 PDT
From: Fischer.pa@Xerox.ARPA
Subject: Re: Comments on Array Summary.
In-reply-to: greek@DEC-HUDSON.ARPA's message of Thu, 27 Jun 85 09:52:56
EDT
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@su-ai.ARPA
Message-ID: <850628-141358-1529@Xerox>
It seems that we need a judgement call on whether to copy arrays when
they are undisplaced.
In all cases but #1 you could specify :initial-contents or
:initial-element. Case #1 supposes that :displaced-to was specified.
Case #4. You're right, one could choose to not copy the block when the
array was shrinking. I believe this is what the Spice CommonLisp code
does.
:element-type seemed pretty clear. It is treated as an error test,
signalling if the array cannot hold elements of that type.
Regarding fill pointers: the case that seems ambiguous is vector-pop.
It signals an error if the fill pointer is zero, and only then. If a
vector is shrunk to a size smaller than where the fill pointer points,
what do we do? vector-push and vector-push-extend seem clear about what
to do, return nil or enlarge the vector.
(ron)
∂01-Jul-85 0803 FAHLMAN@CMU-CS-C.ARPA Comments on Array Summary.
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Jul 85 08:03:16 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 1 Jul 85 11:03:17-EDT
Date: Mon, 1 Jul 1985 11:03 EDT
Message-ID: <FAHLMAN.12123537975.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Fischer.pa@XEROX.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Comments on Array Summary.
In-reply-to: Msg of 28 Jun 1985 17:12-EDT from Fischer.pa at Xerox.ARPA
I see no compelling reason to do array-copying when a previously
displaced array is undisplaced. If you change displacement to a
different array you get new contents; by analogy, if you change
displacement to no existing array, it seems perfectly reasonable that
you would get a fresh array, observing :initial-contents or
:initial-element if they are specified, and with the default emptiness
otherwise. What we want to do is handle this odd case without leaving
an ugly scar in the language, and it seems to me that this behavior is
no more surprising or illogical any other. If people want to copy the
target array and displace to that, that is easy enough to do.
-- Scott
∂01-Jul-85 0854 DLW@SCRC-STONY-BROOK.ARPA Unable to deliver letter
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Jul 85 08:54:32 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 265943; Sun 30-Jun-85 14:19:28-EDT
Date: Tuesday, 25 June 1985, 13:46-EDT
From: Postmaster at SCRC-QUABBIN.ARPA
Subject: Unable to deliver letter
To: DLW@SCRC-QUABBIN
Resent-To: common-lisp@SU-AI.ARPA
Resent-From: DLW@SCRC-QUABBIN.ARPA
Resent-Date: Sun, 30 Jun 85 14:24 EDT
Resent-Message-ID: <850630142456.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Unable to deliver letter to the following recipient:
gls%Aquinas@THINK: Host not responding.
----- Text of letter follows -----
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 172966; Tue 18-Jun-85 11:56:52-EDT
Date: Tue, 18 Jun 85 11:57 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: [TYSON@SRI-AI.ARPA: APPEND in Common-LISP]
To: gls%Aquinas@THINK.ARPA
Message-ID: <850618115747.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Reply-To: dlw@SCRC-STONY-BROOK.ARPA
This message shows a slight confusion from the wording of APPEND's
documentation. My understanding is that what Symbolics CL does is
correct, and the manual faked Mabry out by making him think that "APPEND
always returns a list" is always true for all valid arguments. Maybe
the wording can be made a bit more explicit in the next revision.
Date: Mon, 17 Jun 85 20:58 PDT
From: Mabry Tyson <TYSON@SRI-AI.ARPA>
Subject: APPEND in Common-LISP
To: dlw@SCRC-STONY-BROOK.ARPA
Fcc: B:>tyson>mail>MYMAIL.mail
Message-ID: <850617205802.3.TYSON@BISHOP.ARPA>
I was going to write a longish message about how APPEND had problems
with a single atomic argument and dotted lists as arguments but I
finally realized CL gets out of it via the statement that its arguments
are lists and thus are presumed to be true lists... If you don't pass
it the expected arguments, anything may happen with perhaps no error
message.
So, while the argument list specifies "lists" which must be presumed to
be true lists (since it can be interpreted differently if passed dotted
lists) but it gleefully returns "lists" which specifically may be dotted
lists. (At least two interpretations are available: cause an error or
ignore the non-list cdr -- ie, ignore the fact the user passed illegal
arguments.)
I still object to the fact, in SCL, that (APPEND 'A) = A though! At
least that one ought to get an error message. Hmmmm... This one may be
a legal call to APPEND (since "The last argument actually need not be a
list..") but it does not return a list ("The result is a list ..."). At
least one version of PSL returns NIL for (APPEND 'A) {It ignores the
non-list first argument as though it had just CDRed down to it. Then it
takes the second arg (NIL) as the value.} So, is (APPEND 'A) a legal
call to append and the "The result is a list..." is invalid?
At least UCILisp, or at least the version from Texas, was careful with
such things! I feel that programmers tend to err here and need some
protection. Maybe someday we will have a super-safe version of CL that
will do such error checking.
∂01-Jul-85 1118 FAHLMAN@CMU-CS-C.ARPA Unable to deliver letter
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Jul 85 11:17:59 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 1 Jul 85 14:17:48-EDT
Date: Mon, 1 Jul 1985 14:17 EDT
Message-ID: <FAHLMAN.12123573389.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: DLW@SCRC-QUABBIN.ARPA
Cc: Common-lisp@SU-AI.ARPA
Subject: Unable to deliver letter
In-reply-to: Msg of 25 Jun 1985 13:46-EDT from Postmaster at SCRC-QUABBIN.ARPA
It seems reasonably clear to me from the description in the manual that
(append 'a) is legal and evaluates to 'a. I guess the manual is just
ambiguous enough to confuse people coming from other Lisps where things
don't work this way, so a little tightening of the language is called
for, but I don't think that there is any question about what the right
thing is here.
-- Scott
∂01-Jul-85 1321 greek@DEC-HUDSON Common LISP Registry
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 1 Jul 85 13:21:08 PDT
Date: Mon, 01 Jul 85 16:20:41 EDT
From: greek@DEC-HUDSON
Subject: Common LISP Registry
To: common-lisp@su-ai
I've gotten so few responses about my proposal for a Common LISP
Registry. I'm suspicious. All the responses have been positive,
which makes me even more suspicious.
Are folks out there really interested, and do you intend to use
the registry. Are the TIs, HPs, Symbolicses, and LMIs on the
list going to use the Registry. If not, of course, it won't
work, and I don't feel like wasting my time setting it up.
- Paul
∂04-Jul-85 1249 Kahn.pa@Xerox.ARPA multiple slot descriptions of the same slot in a DEFSTRUCT
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 4 Jul 85 12:49:23 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 JUL 85 12:49:42 PDT
Date: 4 Jul 85 12:49 PDT
From: Kahn.pa@Xerox.ARPA
Subject: multiple slot descriptions of the same slot in a DEFSTRUCT
To: Common-Lisp@SU-AI.ARPA
cc: Kahn.pa@Xerox.ARPA
Message-ID: <850704-124942-1313@Xerox>
What does the following mean?
(defstruct foo (a 0) (a 1))
is it equivalent to
(defstruct foo (a 1))
Along the same lines, is it an error when using the :include option to
"over-ride" a default as follows
(defstruct (bar (:include foo)) (a 2))
or does this work as well as the advertised:
(defstruct (bar (:include foo (a 2)))
∂05-Jul-85 1317 Moon@SCRC-STONY-BROOK.ARPA multiple slot descriptions of the same slot in a DEFSTRUCT
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Jul 85 13:17:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 269509; Fri 5-Jul-85 16:17:16-EDT
Date: Fri, 5 Jul 85 16:16 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: multiple slot descriptions of the same slot in a DEFSTRUCT
To: Kahn.pa@XEROX.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <850704-124942-1313@Xerox>
Message-ID: <850705161654.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 4 Jul 85 12:49 PDT
From: Kahn.pa@Xerox.ARPA
What does the following mean?
(defstruct foo (a 0) (a 1))
....Along the same lines, is it an error when using the :include option to
"over-ride" a default as follows
(defstruct (bar (:include foo)) (a 2))
....
In my opinion both of these errors. Each defstruct slot must have a
distinct name and it is beyond defstruct's scope to attempt to merge
together information from multiple sources about a single slot. Let's
not get into object-oriented inheritance issues in something as
supposedly simple and straightforward as defstruct!
∂05-Jul-85 1559 Masinter.pa@Xerox.ARPA Re: multiple slot descriptions of the same slot in a DEFSTRUCT
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 5 Jul 85 15:59:09 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 05 JUL 85 15:56:59 PDT
Date: 5 Jul 85 15:57 PDT
From: Masinter.pa@Xerox.ARPA
Subject: Re: multiple slot descriptions of the same slot in a DEFSTRUCT
In-reply-to: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>'s message of
Fri, 5 Jul 85 16:16 EDT
To: Moon@SCRC-STONY-BROOK.ARPA
cc: Common-Lisp@SU-AI.ARPA
Message-ID: <850705-155659-1763@Xerox>
As you may know (since I talked to DLW about this last week), "getting
into object-oriented inheritance issues in something as supposedly
simple and straightfoward as defstruct" is just what we're up to.
We hope to have a proposal out to common-lisp-objects in the next couple
of days -- unless there's an overwhelming interest in sending it out to
the global list.
∂11-Jul-85 0917 Gall.HIS←Guest@MIT-MULTICS.ARPA flet and labels
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 11 Jul 85 09:17:48 PDT
Date: Thu, 11 Jul 85 12:12 EDT
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: flet and labels
To: common-lisp@SU-AI.ARPA
Message-ID: <850711161211.939102@MIT-MULTICS.ARPA>
Two Questions:
1. Sorry to repeat myself, but are the function-name bindings done by flet
and labels (a) of lexical scope and indefinite extent, or (b) of lexical scope
and dynamic extent. I believe that the answer was (a), but I lost my copy of
the orig. q/a.
2. Where is the common-lisp mail-list archive? (so I won't have to repeat
questions in the future)
-- Nick
∂11-Jul-85 1033 Moon@SCRC-STONY-BROOK.ARPA flet and labels
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jul 85 10:30:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 273051; Thu 11-Jul-85 13:29:47-EDT
Date: Thu, 11 Jul 85 13:30 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: flet and labels
To: Nick Gall <Gall@MIT-MULTICS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850711161211.939102@MIT-MULTICS.ARPA>
Message-ID: <850711133003.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 11 Jul 85 12:12 EDT
From: Nick Gall <Gall@MIT-MULTICS.ARPA>
Two Questions:
1. Sorry to repeat myself, but are the function-name bindings done by flet
and labels (a) of lexical scope and indefinite extent, or (b) of lexical scope
and dynamic extent. I believe that the answer was (a), but I lost my copy of
the orig. q/a.
(a).
GLS: This information is on pp.40-41 of the manual, but should be repeated in briefer
form on pages 39 and 113.
2. Where is the common-lisp mail-list archive? (so I won't have to repeat
questions in the future)
SU-AI:COMMON.MSG[COM,LSP]
∂11-Jul-85 1225 RPG Archives
To: common-lisp@SU-AI.ARPA
The archives are, in order of earliest through most recent:
COMMON.1[COM,LSP]
COMMON.2[COM,LSP]
COMMON.3[COM,LSP]
COMMON.4[COM,LSP]
COMMON.MSG[COM,LSP]
on SAIL (Su-AI). No login or password required to FTP or TYPE them.
-rpg-
∂12-Jul-85 0937 marick@GSWD-VMS Proposal for a UNIX subgroup.
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 12 Jul 85 09:37:16 PDT
Date: Fri, 12 Jul 85 11:37:34 CDT
From: marick@GSWD-VMS
Subject: Proposal for a UNIX subgroup.
To: common-lisp@su-ai
Cc: marick@gswd-vms
There are at least four companies working on implementations of Common Lisp
for some flavor of UNIX. It would, I think, be to everyone's benefit if
the implementations were as compatible as possible (so that, for example,
OPEN :IF-EXISTS keywords meant the same things in all implementations).
I wouldn't mind seeing a UNIX superset standard, but just giving implementors
a way to talk together would be useful.
To that end, I propose yet another mailing list, Common-Unix. I volunteer
to prime the pump by generating proposals from our own design.
Anyone interested?
Brian Marick
Gould CSD - Urbana
∂12-Jul-85 1036 fateman%ucbdali@Berkeley Re: Proposal for a UNIX subgroup.
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 12 Jul 85 10:36:04 PDT
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/5.2)
id AA00517; Fri, 12 Jul 85 10:31:30 pdt
Received: by ucbdali.ARPA (4.24/4.48)
id AA26130; Fri, 12 Jul 85 10:19:49 pdt
Date: Fri, 12 Jul 85 10:19:49 pdt
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8507121719.AA26130@ucbdali.ARPA>
To: common-lisp@su-ai
Subject: Re: Proposal for a UNIX subgroup.
Cc: marick@gswd-vms
there are presumably a few universities involved in similar things
(e.g. UC Berkeley will have a UNIX-like system on a reduced instruction
set multi-processor (SPUR)), so I would extend your invitation to universities;
also, while we are targeting subgroups, maybe there should be a common-lisp
multi-processing subgroup standardization (e.g. qlambda, multilisp,
spur-lisp, others?).. or more likely, a minimum agreement not to tread on
each others' name space.
∂12-Jul-85 1107 FAHLMAN@CMU-CS-C.ARPA Proposal for a UNIX subgroup.
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Jul 85 11:05:50 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 12 Jul 85 14:05:57-EDT
Date: Fri, 12 Jul 1985 14:05 EDT
Message-ID: <FAHLMAN.12126454831.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: marick@GSWD-VMS.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Proposal for a UNIX subgroup.
In-reply-to: Msg of 12 Jul 1985 12:37-EDT from marick at GSWD-VMS
I think that it is a good idea for the Common Lisp/Unix people to be
talking about ways of being maximally compatible. The participants will
have to decide for themselves how much standardization makes sense here.
For example, I'm sure that it is more important to DEC that their own
VMS and Unix versions agree than that their Unix version matches someone
else's. Same for Lucid, which is working on Unix-based and
non-Unix-based versions and needs to keep them all in sync. But even
given these constraints, a little communication would keep down the
amount of truly needless incompatibility.
Let me suggest that the people who want to communicate about this stuff
do it on the Common Lisp mailing list for now. I don't think it would
hurt the rest of us to hear what's going on in this area -- maybe some
of the decisions have consequences outside unix-land. If the traffic
gets too heavy, or too irrelevant to the rest of the community, then we
can split it off.
-- Scott
∂21-Jul-85 1743 RPG Simple Minds
To: quinquevirate@SU-AI.ARPA
Here's a suggestion to baffle the Common Lisp masses: 2 new
constants - mst--ppositive-bignu and most-negative-bignum.
-rpg-
∂22-Jul-85 1043 gls@THINK-AQUINAS.ARPA Simple Minds
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 22 Jul 85 10:43:44 PDT
Received: by THINK.ARPA with CHAOS; Mon, 22 Jul 85 13:42:11 edt
Date: Mon, 22 Jul 85 13:43 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Simple Minds
To: RPG@SU-AI.ARPA, quinquevirate@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 21 Jul 85 20:43-EDT from Dick Gabriel <RPG at SU-AI>
Message-Id: <850722134347.3.GLS@UBALDO.ARPA>
Received: from GODOT by AQUINAS via CHAOS with CHAOS-MAIL; Sun 21-Jul-85 20:46:48-EDT
Received: from SU-AI.ARPA (su-ai.arpa.ARPA) by THINK.ARPA; Sun, 21 Jul 85 20:45:03 edt
Date: 21 Jul 85 1743 PDT
From: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Simple Minds
To: quinquevirate@SU-AI.ARPA
Here's a suggestion to baffle the Common Lisp masses: 2 new
constants - mst--ppositive-bignu and most-negative-bignum.
-rpg-
Presumably each one occupies about 1/3 of your total otherwise-available
address space.
--Quux
∂26-Jul-85 1103 KMP@SCRC-STONY-BROOK.ARPA CHAR-BIT
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 11:03:20 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 283054; Fri 26-Jul-85 14:02:14-EDT
Date: Fri, 26 Jul 85 14:02 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: CHAR-BIT
To: COMMON-LISP@SU-AI.ARPA
Message-ID: <850726140224.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
At the top of page 244, it says that it is an error to give this the name of a bit
that doesn't exist in a given implementation. This is a loss because it means that
users then have to
* know which bits are supported where
* write code to know it.
Consider:
(DEFUN HAS-HYPER-BIT-P (CHAR)
#+Symbolics (CHAR-BIT CHAR :HYPER)
#-Symbolics NIL)
This sort of definition bothers me. Even the non #'d variant:
(DEFUN HAS-HYPER-BIT-P (CHAR)
(IF THIS-IMPLEMENTATION-HAS-A-HYPER-BIT-P (CHAR-BIT CHAR :HYPER)))
bothers me since the compiler is no doubt going to warn me about using
CHAR-BIT with an invalid argument. I suppose I have to write:
(DEFMACRO IF-THIS-IMPLEMENTATION-HAS-A-HYPER-BIT (&BODY FORMS)
(IF THIS-IMPLEMENTATION-HAS-A-HYPER-BIT-P `(PROGN ,@FORMS) `NIL))
(DEFUN HAS-HYPER-BIT-P (CHAR)
(IF-THIS-IMPLEMENTATION-HAS-A-HYPER-BIT (CHAR-BIT CHAR :HYPER)))
to avoid that.
And what if I was wrong? What if some other implementations allow a Hyper bit
that I don't know about. eg, what if there were another LispM company besides
Symbolics or what if the DEC VT1000 has a Hyper key? Does that mean his code
should be wrong? Isn't it reasonable for him to predicate Hyper-ness of a
character even though it will never be Hyper?
Also, there will certainly be keyboards that can't generate a Hyper key even in
machine implementations that could accept it; in those cases, it certainly makes
sense to ask about bits that couldn't exist.
The point is that conceptually it makes sense to allow this and implementationally
it's possible to make these efficient. eg, (CHAR-BIT char :HYPER) can optimize to
NIL at compile time in some implementations, and it's probably ok for
(CHAR-BIT char X) to be a bit slower.
So I believe I should be able to simply do
(CHAR-BIT CHAR :HYPER)
and reliably get NIL in implementations that do not support the Hyper key.
As to SET-CHAR-BIT, I am content to have an error generated when I try to set
a non-existent bit. This happens, I suspect, less frequently. [In fact, the only
case I can think of where it would ever happen at all is where someone is writing
code (eg, for an editor) that offers a Hyper- escape for keyboards that can't
generate such characters primitively.] I am willing to specially conditionalize
such cases.
In principle, there may be implementations that don't support even the :CONTROL bit.
For the sake of such implementations, are you willing to conditionalize your
uses of (CHAR-BIT CHAR :CONTROL) in order to be able to truthfully claim portability?
-kmp
∂26-Jul-85 1159 KMP@SCRC-STONY-BROOK.ARPA Clearing the screen and other such things.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 11:58:44 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 283113; Fri 26-Jul-85 14:48:52-EDT
Date: Fri, 26 Jul 85 14:49 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Clearing the screen and other such things.
To: COMMON-LISP@SU-AI.ARPA
Message-ID: <850726144908.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
As nearly as I can tell, Common Lisp offers no way to even clear the
screen. In the absence of a graphics standard, can we commit to even
something so simple as a CLEAR-SCREEN function? In fact, I'd like to see
as many of the functions below as we could agree on; please note that
this suggestion is not meant to preclude a more sophisticated graphics
proposal. It is only meant to acknowledge the fact that many interesting
portable applications can be written using a single fixed width fonts
and character coordinates. Note also that some of these functions might
later want more arguments added, but I've deliberately kept them as simple
as possible for now so as not to preempt decisions that might be made by
the graphics group.
-kmp
ERASE-SCREEN &optional (screen *TERMINAL-IO*)
Erases the text on the entire screen. On screens which do not
support this operation, a fresh-line is done instead.
ERASE-REST-OF-SCREEN &optional (screen *TERMINAL-IO*)
Erases the text on the rest of the screen beginning at the point of
the cursor. On screens which do not support this operation, a
fresh-line is done instead.
ERASE-REST-OF-LINE &optional (screen *TERMINAL-IO*)
Clears the rest of the line (from the point of the cursor).
On screens which do not support this operation, a linefeed is done
is done instead.
ERASE-CHAR-BACKWARD &optional (screen *TERMINAL-IO*)
Erases the character before the cursor. Undefined if called at head
of line.
ERASE-CHAR-FORWARD &optional (screen *TERMINAL-IO*)
Erases the character after the cursor. Undefined if called at end
of line.
CURSOR-BACKWARD &optional (screen *TERMINAL-IO*)
Moves the cursor back one character. Undefined if called at head of
line.
CURSOR-FORWARD &optional (screen *TERMINAL-IO*)
Moves the cursor forward one character. Undefined if called at end
of line.
CURSOR-DOWN &optional (screen *TERMINAL-IO*)
Moves the cursor down one character. Undefined if called at bottom
of screen.
CURSOR-UP &optional (screen *TERMINAL-IO*)
Moves the cursor up one character. Undefined if called at top of
screen.
CURSOR-HOME-UP &optional (screen *TERMINAL-IO*)
Moves the cursor to the top left corner of the screen.
CURSOR-HOME-DOWN &optional (screen *TERMINAL-IO*)
Moves the cursor to the bottom left corner of the screen.
INSERT-CHAR &optional (screen *TERMINAL-IO*)
Opens a position in front of the cursor for display of a character
using the Insert-Char operation supported by most modern terminals.
The effect of INSERT-CHAR when there is a character in the last
position on the line is undefined.
DELETE-CHAR &optional (screen *TERMINAL-IO*)
Deletes the character in front of the cursor using the standard
Delete-Char operation supported by most modern terminals. The effect
of DELETE-CHAR at the end of a line is undefined.
INSERT-LINE &optional (screen *TERMINAL-IO*)
Opens the line at the cursor by sliding the remaining lines on
the screen down using the Insert-Line operation supported by most
modern terminals. The effect of calling this when not in column 0
is undefined.
DELETE-LINE &optional (screen *TERMINAL-IO*)
Deletes the line at the cursor, sliding the remaining lines on the
screen up using the standard Delete-Line operation supported by most
modern terminals. The effect of calling this when not in column 0
is undefined.
CHARACTER-POSITION &optional (screen *TERMINAL-IO*)
Returns two values representing the character position (X,Y) of the
cursor on the given screen in character units (assuming a fixed
width font). It should be possible to say
(SETF (CHARACTER-POSITION) (VALUES x y)) to
later restore the cursor to the given coordinates.
SCREEN-SIZE-IN-CHARACTERS &optional (screen *TERMINAL-IO*)
Returns two values representing the size of the screen in characters (X,Y).
SCREEN-OPERATION-HANDLED-P operation &optional (screen *TERMINAL-IO*)
Takes an argument of the name of a screen operation and returns
true if that operation is correctly handled on the current screen. eg,
(SCREEN-OPERATION-HANDLED-P 'DELETE-LINE)
would be handled only on screens with Delete-Line capability.
Some operations, such as CLEAR-SCREEN, will be simulated even if this
returns false. For example, (SCREEN-OPERATION-HANDLED-P 'CLEAR-SCREEN)
may sometimes return false but the CLEAR-SCREEN operation will never signal
an error.
SCREEN-TYPE screen
Returns a keyword which is one of:
:DISPLAY The screen handles all of the above display operations.
:CURSOR-MOTION The screen handles all display operations except the
INSERT-xxx and DELETE-xxx operations.
:GLASS The screen handles ERASE-CHARACTER-BACKWARD.
:PRINTING The screen is a paper terminal and handles none of the
display operations.
:OTHER The screen is of some type not adequately described by one
of these categories. SCREEN-OPERATION-HANDLED-P should be
used to determine specifically what type of terminal is involved.
∂26-Jul-85 1215 KMP@SCRC-STONY-BROOK.ARPA Does READ-CHAR echo?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 12:15:00 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 283120; Fri 26-Jul-85 15:02:18-EDT
Date: Fri, 26 Jul 85 15:02 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Does READ-CHAR echo?
To: Common-Lisp@SU-AI.ARPA
cc: CWH@SCRC-STONY-BROOK.ARPA
Message-ID: <850726150233.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I could not find any place in CLtL where it says whether READ-CHAR echos
the character that it has read. Likewise for PEEK-CHAR. Also, there is
no discussion of whether UNREAD-CHAR should unecho the character.
I note that Symbolics Common Lisp has (somewhat arbitrarily, I guess)
decided that READ-CHAR echos, PEEK-CHAR does not echo, and UNREAD-CHAR
does not un-echo the character. This has the odd effect that:
(PROGN (PEEK-CHAR) (UNREAD-CHAR (READ-CHAR)) (READ-CHAR))
echos the character twice. I imagine it will be a real hassle when programs
start porting if this behavior does not become standardized.
Does anyone have any thoughts about whether we should think about adding
functions called PEEK-CHAR-NO-ECHO, READ-CHAR-NO-ECHO, and UNREAD-CHAR-NO-ECHO?
Or maybe there should be WITH-INPUT-ECHO and WITHOUT-INPUT-ECHO special forms
which affect calls to the character readers within the dynamic scope of their
body.
I kind of assume that we all agree that READ and READ-LINE should echo
the characters as they come in from an interactive terminal. Perhaps,
we should state that explicitly in the next edition of the manual.
I believe Carl Hoffman (who wrote the Lisp Machine rubout handler) has
some thoughts on this, which I hope this letter will spur him to share with us.
∂26-Jul-85 1421 RWK@SCRC-YUKON.ARPA Does READ-CHAR echo?
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 14:21:43 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 141347; Fri 26-Jul-85 17:21:16-EDT
Date: Fri, 26 Jul 85 17:21 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Does READ-CHAR echo?
To: KMP@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA
cc: CWH@SCRC-STONY-BROOK.ARPA
In-Reply-To: <850726150233.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <850726172130.7.RWK@CROW.SCRC.Symbolics.COM>
Date: Fri, 26 Jul 85 15:02 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
I could not find any place in CLtL where it says whether READ-CHAR echos
the character that it has read. Likewise for PEEK-CHAR. Also, there is
no discussion of whether UNREAD-CHAR should unecho the character.
I note that Symbolics Common Lisp has (somewhat arbitrarily, I guess)
decided that READ-CHAR echos, PEEK-CHAR does not echo, and UNREAD-CHAR
does not un-echo the character. This has the odd effect that:
(PROGN (PEEK-CHAR) (UNREAD-CHAR (READ-CHAR)) (READ-CHAR))
echos the character twice. I imagine it will be a real hassle when programs
start porting if this behavior does not become standardized.
I would suggest that it is incorrect for READ-CHAR to echo a character
which was UNREAD-CHAR'd. Such a character has already been echoed once.
I think this is just a bug.
Does anyone have any thoughts about whether we should think about adding
functions called PEEK-CHAR-NO-ECHO, READ-CHAR-NO-ECHO, and UNREAD-CHAR-NO-ECHO?
Or maybe there should be WITH-INPUT-ECHO and WITHOUT-INPUT-ECHO special forms
which affect calls to the character readers within the dynamic scope of their
body.
I think the only one needed would be READ-CHAR-NO-ECHO.
∂26-Jul-85 1605 HAUG%ti-csl.csnet@csnet-relay.arpa labels
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 16:05:00 PDT
Received: from ti-csl by csnet-relay.csnet id aa09231; 26 Jul 85 19:00 EDT
Date: 26 Jul 1985 1550-CDT
From: HAUG%CSL60%ti-csl.csnet@csnet-relay.arpa
Subject: labels
To: common-lisp@su-ai.ARPA
Received: from csl60 by ti-csl; Fri, 26 Jul 85 16:41 CST
I use the LABELS construct frequently and recently observed that if
a function FOO is defined via LABELS, use of a (RETURN-FROM FOO ...)
within the body of FOO generates an "undefined block FOO" error in both
our interpreter and compiler. I also looked at the source code for SPICE
(FAHLMAN et al.) and believe that it would generate an error in this
implementation as well. The reason is that a surrounding BLOCK is not
implicitly generated in the case of LABELS. I believe this to be an
oversight in the specification for LABELS.
-- David Haug
-------
∂26-Jul-85 1618 mips!earl@Glacier Does READ-CHAR echo?
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 16:18:16 PDT
Received: by mips.UUCP (4.12/4.7)
id AA24168; Fri, 26 Jul 85 16:13:10 pdt
Date: Fri, 26 Jul 85 16:13:10 pdt
From: mips!earl@Glacier (Earl Killian)
Message-Id: <8507262313.AA24168@mips.UUCP>
To: Glacier!KMP@SCRC-STONY-BROOK.ARPA
Cc: Glacier!Common-Lisp@SU-AI.ARPA, Glacier!CWH@SCRC-STONY-BROOK.ARPA
In-Reply-To: Kent M Pitman's message of Fri, 26 Jul 85 15:02 EDT
Subject: Does READ-CHAR echo?
Does READ-CHAR echo, or does the terminal handler, which supplied the
character in the first place, echo? Echoing is terminal-specific
(you don't want READ-CHAR from a file to echo) so it makes more sense
to talk about what the terminal handler does. This starts to get
into the controversy over whether you want to echo the character when
it is typed ("interrupt level") or when it is read, or try to rise
above these simple alternatives to do the right thing. Does Common
Lisp specify whether echoing is done at type-in time or read-time?
Probably it should leave such things undefined so that you can use
system echoing for efficiency, or try to do something better than
either of the simple alternatives. Leaving it undefined makes it
difficult to write portable rubout handlers (because you can't know
the state the screen), but my guess is that these will be provided by
the underlying implementation. The underlying implementation should
of course promise to echo things exactly once; your problem with
UNREAD-CHAR in ZetaLisp sounds like a simple bug.
∂26-Jul-85 1638 mips!earl@Glacier Clearing the screen and other such things.
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 16:38:35 PDT
Received: by mips.UUCP (4.12/4.7)
id AA25005; Fri, 26 Jul 85 16:35:42 pdt
Date: Fri, 26 Jul 85 16:35:42 pdt
From: mips!earl@Glacier (Earl Killian)
Message-Id: <8507262335.AA25005@mips.UUCP>
To: Glacier!KMP@SCRC-STONY-BROOK.ARPA
Cc: Glacier!COMMON-LISP@SU-AI.ARPA
In-Reply-To: Kent M Pitman's message of Fri, 26 Jul 85 14:49 EDT
Subject: Clearing the screen and other such things.
I'm not sure whether it is a good idea to add such things or not,
but the specific proposal is severely flawed and should be fixed
before being considered.
ERASE-REST-OF-SCREEN is rarely useful, while a function to erase
multiple lines can be quite useful (e.g. N lines from current line).
In general your proposed functions all need to take arguments to do
multiple operations instead of one. It is MUCH easier to expand
DELETE-CHAR N than it is to recognize N consecutive DELETE-CHARs, and
merge them into one terminal operation. However, instead of
INSERT-CHARS N, what you really want is INSERT-STRING, and instead of
INSERT/DELETE-LINES N, what you want is a INSERT/DELETE-LINES N M
which is insert/delete N lines in the M-line region after the current
line (again, this is easy to simulate on terminals with simple
insert-delete line commands, but pattern recognizing the other
direction is difficult). You can apply the same technique if you
want to INSERT/DELETE-CHARS, and indeed to ERASE-LINE, by giving a
column to stop at, making it easy to support windowing. Erase-to-column
is the only one that can't be efficiently supported on your average
terminal (requiring the typeout of lots of spaces if the column
in question isn't the last column of the screen).
∂26-Jul-85 2357 TIM@MIT-MC.ARPA labels
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 23:57:01 PDT
Date: Sat, 27 Jul 85 02:57:55 EDT
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject: labels
To: HAUG%CSL60%ti-csl.csnet@CSNET-RELAY.ARPA
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of 26 Jul 1985 1550-CDT from HAUG%CSL60%ti-csl.csnet at csnet-relay.arpa
Message-ID: <[MIT-MC.ARPA].590070.850727.TIM>
Date: 26 Jul 1985 1550-CDT
Re: labels
... a surrounding BLOCK is not implicitly generated in the case
of LABELS. I believe this to be an oversight in the specification
for LABELS.
-- David Haug
I agree. Functions defined with LABELS and FLET should have the same
implicit BLOCK as functions defined with DEFUN.
Tim McNerney
P.S. This is "broken" (but by the book) in Symbolics Common Lisp as well.
∂27-Jul-85 0210 TIM@MIT-MC.ARPA Clearing the screen and other such things.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Jul 85 02:10:27 PDT
Date: Sat, 27 Jul 85 05:11:22 EDT
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject: Clearing the screen and other such things.
To: KMP@SCRC-STONY-BROOK.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-reply-to: Msg of Fri 26 Jul 85 14:49 EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Message-ID: <[MIT-MC.ARPA].590150.850727.TIM>
Date: Fri, 26 Jul 85 14:49 EDT
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
As nearly as I can tell, Common Lisp offers no way to even clear the
screen. In the absence of a graphics standard, can we commit to even
something so simple as a CLEAR-SCREEN function?
I agree that Common Lisp should have better terminal support, but beyond
CLEAR-SCREEN, things are not so simple. Some issues (and mere details)
need to be settled on before we extend the language in this direction:
ERASE-REST-OF-SCREEN, ERASE-REST-OF-LINE,
INSERT-CHAR, DELETE-CHAR, INSERT-LINE, DELETE-LINE
Should these functions return T or NIL depending on whether there was any
effect on the screen?
ERASE-CHAR-BACKWARD, ERASE-CHAR-FORWARD
Many terminals don't support these operations. If we are trying to limit
ourselves to a set of essential primitives, I would suggest that these be
flushed, since they are merely abstractions for printing the sequences,
backspace-space-backspace and space-backspace, respectively.
CURSOR-BACKWARD, CURSOR-FORWARD, CURSOR-DOWN, CURSOR-UP,
CURSOR-HOME-UP, CURSOR-HOME-DOWN
Should these return the cursor position, or either T or NIL depending on
whether there was any effect (like the ERASE-xxx functions)?
CHARACTER-POSITION
Should all Common Lisp implementations be required to accurately model the
the terminal's cursor position? In the discussion of TERPRI, FRESH-LINE,
and FORMAT, in CLtL, it is stated explicitly that the implementation not be
required to do so. This is a wise decision, because this is not always
possible, expecially if the operating system is allowed to randomly print
out notices without telling the Lisp. Also, some terminals move the cursor
to the next line after printing in the last column, and some terminals
scroll the screen up one line after printing in the last column of the last
screen line! This can be a source of problems. (...and some terminals are
just plain spastic; remember how TTY's occasionally skipped spaces, etc?)
(SETF (CHARACTER-POSITION) (VALUES x y))
There should probably be a function SET-CHARACTER-POSITION which the above
SETF form expands into. I would prefer the names CURSOR-POSITION and
SET-CURSOR-POSITION so as to be consistent with the names of the cursor
motion functions.
SCREEN-SIZE-IN-CHARACTERS
Presumably this will return the page size for printing terminals too.
How about a more generic name like TERMINAL-SIZE-IN-CHARACTERS?
SCREEN-TYPE
I would prefer the name TERMINAL-TYPE.
SCREEN-OPERATION-HANDLED-P
Similarly, I would prefer TERMINAL-OPERATION-HANDLED-P
[terminal-type]
:OTHER The screen is of some type not adequately described by one
of these categories. SCREEN-OPERATION-HANDLED-P should be
used to determine specifically what type of terminal is
involved.
This seems like an overly painful way of finding out the charateristics of
a terminal. Perhaps TERMINAL-TYPE should return as a second value the list
of functions names the terminal it supports (something akin to the list
returned by a :WHICH-OPERATIONS method in Flavors).
Tim McNerney
P.S. If these function were put into the language (white pages), Common
Lisp may be the first language standard to acknowledge the existence of
display terminals!
∂27-Jul-85 1137 fateman%ucbdali@Berkeley Re: Clearing the screen and other such things.
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 27 Jul 85 11:37:32 PDT
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/5.3)
id AA20272; Sat, 27 Jul 85 11:32:52 pdt
Received: by ucbdali.ARPA (5.5/4.48)
id AA20272; Sat, 27 Jul 85 11:38:16 PDT
Date: Sat, 27 Jul 85 11:38:16 PDT
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8507271838.AA20272@ucbdali.ARPA>
To: KMP@SCRC-STONY-BROOK.ARPA, TIM@MIT-MC.ARPA
Subject: Re: Clearing the screen and other such things.
Cc: COMMON-LISP@SU-AI.ARPA
Doesn't UNIX (4.0, 4.1, 4.2 BSD) and those derived from it (e.g. Xenix)
have a cursor-control package, and aren't there editors (e.g. vi, gnumacs,
Gosling emacs) that use the termcap (or similar) information files?
I believe that Franz Lisp provides a set of primitives to do all this
character-screen oriented stuff (to the extent it is supported by Unix).
∂27-Jul-85 1334 TIM@MIT-MC.ARPA Clearing the screen and other such things.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Jul 85 13:34:23 PDT
Date: Sat, 27 Jul 85 16:35:16 EDT
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject: Clearing the screen and other such things.
To: fateman@UCBDALI.ARPA
cc: COMMON-LISP@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of Sat 27 Jul 85 11:38:16 PDT from fateman%ucbdali at Berkeley (Richard Fateman)
Message-ID: <[MIT-MC.ARPA].590458.850727.TIM>
Date: Sat, 27 Jul 85 11:38:16 PDT
From: fateman%ucbdali at Berkeley (Richard Fateman)
Doesn't UNIX (4.0, 4.1, 4.2 BSD) and those derived from it (e.g. Xenix)
have a cursor-control package, and aren't there editors (e.g. vi, gnumacs,
Gosling emacs) that use the termcap (or similar) information files?
Termcap does not address some of the subtleties of many terminals.
For instance: Does the terminal scroll after printing a character in
the last column of the last like? Also, many terminals support
operations like "Delete N lines," which are almost indispensable for
writing screen editors and the like, are not supported by termcap (nor
KMP's proposal). Then there is the issue of padding which is not
modeled well at all by termcap.
But, unix aside, because Common Lisp is supposed to be operating
system and machine independent, designing generic I/O in general is
problematic. Witness the problems that have been raised w.r.t.
interfacing with various files systems (eg. OPEN's :direction :probe).
∂27-Jul-85 2111 WHOLEY@CMU-CS-C.ARPA Clearing the screen and other such things.
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Jul 85 21:10:57 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Sun 28 Jul 85 00:11:55-EDT
Date: Sun, 28 Jul 1985 00:11 EDT
Message-ID: <WHOLEY.12130497295.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Clearing the screen and other such things.
In-reply-to: Msg of 26 Jul 1985 14:49-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Date: Friday, 26 July 1985 14:49-EDT
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
To: COMMON-LISP at SU-AI.ARPA
Re: Clearing the screen and other such things.
As nearly as I can tell, Common Lisp offers no way to even clear the
screen. In the absence of a graphics standard, can we commit to even
something so simple as a CLEAR-SCREEN function? In fact, I'd like to see
as many of the functions below as we could agree on; please note that
this suggestion is not meant to preclude a more sophisticated graphics
proposal. It is only meant to acknowledge the fact that many interesting
portable applications can be written using a single fixed width fonts
and character coordinates.
However many months ago all of those wonderful "special interest group"
CL-mumble mailing lists were set up, I thought that such a thing would be what
the CL-Windows group would try to put together first. Instead, people in the
group got caught up in worrying about "real" (read "hairy, ANSI, and COBOLISH")
window/graphics systems and how one might get Lisp to talk to them.
I would really like to see a well-specified pseudo-standard text window system
that has enough hooks for, say, a text editor wanting to do reasonably clever
redisplay. We should be able to agree on something at about the level of what
KMP proposed, I should hope. This is something a lot of us want, but doesn't
exactly fall in the domains of either the CL-Graphics or CL-Windows groups.
We could perhaps create a CL-Text-Windows group for just such a thing.
Or perhaps we should keep it "out here in the open", where issues don't die as
easily as in the smaller groups.
Or a bunch of us could do things with a private mailing list, implement this
thing for our various Common Lisps, and present it (perhaps along with
semi-portable code to implement stuff) to the Common Lisp community when we
like what we've got.
Any takers on any of the above?
--Skef
∂28-Jul-85 1430 RAM@CMU-CS-C.ARPA Clearing the screen and other such things.
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 28 Jul 85 14:30:36 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Sun 28 Jul 85 17:31:49-EDT
Date: Sun, 28 Jul 1985 17:31 EDT
Message-ID: <RAM.12130686608.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Clearing the screen and other such things.
In-reply-to: Msg of 26 Jul 1985 14:49-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
It may or may not be a good idea to have a Common Lisp virtual
terminal, as is being suggested, but in any case, I think it is
important that this idea not be confused with the default stream
terminal I/O. I think it would be a bad idea to force the default
stream interaction into a fixed-width character-oriented model.
Whatever interface is chosen should be willing to admit the
possibility of virtual terminal emulation being done in a totally
different fashion that default terminal I/O.
As a case in point, default terminal interaction in Spice Lisp is
done by a remote procedure call interface to the typescript server,
which is basically a base editor. The Typescript server doesn't
provide any facility such as "cursor positioning" since this doesn't
fit into the stream-oriented paradigm on which it is based. If we
wanted to provide virtual terminal emulation, we would have to do it
using a totally different mechanism, operating on a different piece of
the screen.
Rob
∂28-Jul-85 2205 TIM@MIT-MC.ARPA Clearing the screen and other such things.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 28 Jul 85 22:05:04 PDT
Date: Mon, 29 Jul 85 01:06:02 EDT
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject: Clearing the screen and other such things.
To: RAM@CMU-CS-C.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-reply-to: Msg of Sun 28 Jul 1985 17:31 EDT from Rob MacLachlan <RAM at CMU-CS-C.ARPA>
Message-ID: <[MIT-MC.ARPA].591637.850729.TIM>
Date: Sun, 28 Jul 1985 17:31 EDT
From: Rob MacLachlan <RAM at CMU-CS-C.ARPA>
It may or may not be a good idea to have a Common Lisp virtual
terminal, as is being suggested, but in any case, I think it is
important that this idea not be confused with the default stream
terminal I/O. I think it would be a bad idea to force the default
stream interaction into a fixed-width character-oriented model.
Whatever interface is chosen should be willing to admit the
possibility of virtual terminal emulation being done in a totally
different fashion that default terminal I/O.
Perhaps this "virtual terminal" package would be best put into the yellow
pages. Given a sufficiently efficient implementation of the basic terminal
I/O stream or at least a binary stream to the terminal, it could be written
entirely in Lisp.
A useful bit of white pages support for a virtual terminal package would be
a way for the Lisp to find out whether the operating system has trashed the
screen (by sending out a system notice, or something) thus randomizing the
cursor position, etc. This could be in the form of an "environment query"
function. There should probably be another function which returns T or NIL
depending on whether the implementation supports this feature.
∂29-Jul-85 0136 RAM@CMU-CS-C.ARPA Clearing the screen and other such things.
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 01:36:07 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 29 Jul 85 04:37:20-EDT
Date: Mon, 29 Jul 1985 04:37 EDT
Message-ID: <RAM.12130807766.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Tim McNerney <TIM@MIT-MC.ARPA>
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Clearing the screen and other such things.
In-reply-to: Msg of 29 Jul 1985 01:06-EDT from Tim McNerney <TIM at MIT-MC.ARPA>
Perhaps this "virtual terminal" package would be best put into the
yellow pages. Given a sufficiently efficient implementation of the
basic terminal I/O stream or at least a binary stream to the terminal,
it could be written entirely in Lisp.
This is only true given that there is a physical terminal which can be
controlled by sequences of characters --- a totally unwarranted
assumption.
From an earlier message:
ERASE-CHAR-BACKWARD, ERASE-CHAR-FORWARD
Many terminals don't support these operations. If we are trying to
limit ourselves to a set of essential primitives, I would suggest that
these be flushed, since they are merely abstractions for printing the
sequences, backspace-space-backspace and space-backspace,
respectively.
This argument is not valid, since there is no reason to suppose that
"printing" these characters on the "terminal" will have the desired
effect. A Common Lisp implementation doesn't even have to have a
backspace character.
Rob
∂29-Jul-85 0558 BSG@SCRC-STONY-BROOK.ARPA Clearing the screen and other such things.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 05:58:24 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 283954; Mon 29-Jul-85 08:57:55-EDT
Date: Mon, 29 Jul 85 09:06 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Clearing the screen and other such things.
To: KMP@SCRC-STONY-BROOK.ARPA, mips!earl@SU-GLACIER.ARPA,
TIM@MIT-MC.ARPA, Wholey@CMU-CS-C.ARPA, RAM@CMU-CS-C.ARPA,
COMMON-LISP@SU-AI.ARPA, fateman@UCBDALI.ARPA
cc: Glacier!COMMON-LISP@SU-AI.ARPA
In-Reply-To: <850726144908.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<8507262335.AA25005@mips.UUCP>,
<[MIT-MC.ARPA].590150.850727.TIM>,
<[MIT-MC.ARPA].590458.850727.TIM>,
<WHOLEY.12130497295.BABYL@CMU-CS-C.ARPA>,
<RAM.12130686608.BABYL@CMU-CS-C.ARPA>,
<[MIT-MC.ARPA].591637.850729.TIM>,
<RAM.12130807766.BABYL@CMU-CS-C.ARPA>
Message-ID: <850729090643.0.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Fri, 26 Jul 85 14:49 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
As nearly as I can tell, Common Lisp offers no way to even clear the
screen.
It hurts me to see various sanded-edged parallelipipeds and egg-shaped frobs
being offered for the reinvention of the wheel.
I think all the problems addressed in the referenced messages were solved
pretty adequately by any number of virtual terminal systems in the past
10 years, ITS's seeming to me to be the canonical one.
You provide primitives that are as general and powerful as possible.
Scroll region N lines, Insert entire character string, Delete n lines,
and so forth. You provide an entry that says what capabilities are
available. Extensibly. Auto-CRLF at end of line and every other known
stupid feature, culled from the hundreds of person-years of experience
of Editor Implementors of the Time Sharing Era are assigned standard
names. The support system masks some incompatibilities, like deleting
N lines by loop if there is no Delete N Lines in the terminal.
You do NOT attempt to simulate insertions and deletions, or any feature
X such that an acceptable redisplay program would choose a different
strategy in the absence of X. I think that set is fairly well defined.
The "antsy standard" terminal protocol (e.g., the Ann Arbor Ambassador)
also makes not a bad cut at defining the canonical capabilities
generically.
∂29-Jul-85 0707 greek@DEC-HUDSON A comment on our community.
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 07:07:09 PDT
Date: Mon, 29 Jul 85 10:06:44 EDT
From: greek@DEC-HUDSON
Subject: A comment on our community.
To: common-lisp@su-ai
∂29-Jul-85 0708 greek@DEC-HUDSON A comment on our community.
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 07:08:05 PDT
Date: Mon, 29 Jul 85 10:07:41 EDT
From: greek@DEC-HUDSON
Subject: A comment on our community.
To: common-lisp@su-ai
∂29-Jul-85 0708 greek@DEC-HUDSON A comment on our community.
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 07:08:22 PDT
Date: Mon, 29 Jul 85 10:07:01 EDT
From: greek@DEC-HUDSON
Subject: A comment on our community.
To: common-lisp@su-ai
∂29-Jul-85 0709 greek@DEC-HUDSON A comment on our community.
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 07:09:07 PDT
Date: Mon, 29 Jul 85 10:08:42 EDT
From: greek@DEC-HUDSON
Subject: A comment on our community.
To: common-lisp@su-ai
It seems pretty clear to me that the Common LISP community can't agree
on anything too controversial such as flavors, graphics, error handling,
windows, etc. My experience with trying to set up a registration
service for package names, which has all but died, left me with a similar
feeling. I received notes with comments like "Well, this isn't an
official statement, but my company probably wouldn't use the registrar."
We should all run for Congress. Seriously, though, those of us who
work on existing implementations should admit that we have a vested
interest in our current flavor system, graphics system, etc. Those
of us who work for profit-making organizations should admit that we
want an edge over our competition. And we should all admit that, as
"computer scientists", we're probably some of the most gratuitously
opinionated people around.
If we really can't agree on something, let's just say so and leave it
at that. What I'm really afraid of is oversimplified or abbreviated
proposals which address small subsets of the problem. In particular,
if we ever do manage to agree on the bigger problem, we will end up
with the original burp in Common LISP that looks out of place.
I don't want to attack Kent's proposal as some kind of ill omen, but
these simple character-oriented functions don't address a lot of
problems. How does LISP know how to do them? What do some of
them mean on a bitmapped terminal? Do you really want to try to
program portable algorithms by continually using SCREEN-OPERATION-
HANDLED-P and having multiple code paths? Earl, Tim, and Rob have
pointed out other issues.
Let's face it, windows, graphics, and text display are not solved
problems. Why do we think we can agree on them? Perhaps our time
is better spent on topics we're more likely to resolve, such as a
kernel object-oriented subsystem or error handling facility?
But please let's agree that a lot of politics is involved here.
- Paul
∂29-Jul-85 0954 gls@THINK-AQUINAS.ARPA Clearing the screen and other such things.
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 09:54:00 PDT
Received: by THINK.ARPA with CHAOS; Mon, 29 Jul 85 12:53:32 edt
Date: Mon, 29 Jul 85 12:53 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Clearing the screen and other such things.
To: TIM@MIT-MC.ARPA, KMP@SCRC-STONY-BROOK.ARPA
Cc: COMMON-LISP@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <[MIT-MC.ARPA].590150.850727.TIM>
Message-Id: <850729125323.3.GLS@POLYCARP.ARPA>
Date: Sat, 27 Jul 85 05:11:22 EDT
From: Tim McNerney <TIM@MIT-MC.ARPA>
...
ERASE-CHAR-BACKWARD, ERASE-CHAR-FORWARD
Many terminals don't support these operations. If we are trying to limit
ourselves to a set of essential primitives, I would suggest that these be
flushed, since they are merely abstractions for printing the sequences,
backspace-space-backspace and space-backspace, respectively.
Tim McNerney
...
This remark raises the question of whether the terminal has overstrike
capabilities or not; and if it does not, whether space is transparent
or replacing.
--Guy
∂29-Jul-85 1048 TIM@MIT-MC.ARPA Clearing the screen and other such things.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 10:48:47 PDT
Date: Mon, 29 Jul 85 13:49:44 EDT
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject: Clearing the screen and other such things.
To: BSG@SCRC-STONY-BROOK.ARPA
cc: COMMON-LISP@SU-AI.ARPA, Glacier!COMMON-LISP@SU-AI.ARPA,
RAM@CMU-CS-C.ARPA, Wholey@CMU-CS-C.ARPA,
mips!earl@SU-GLACIER.ARPA, fateman@UCBDALI.ARPA,
KMP@SCRC-STONY-BROOK.ARPA
Message-ID: <[MIT-MC.ARPA].592267.850729.TIM>
Date: Mon, 29 Jul 85 09:06 EDT
From: Bernard S. Greenberg <BSG at SCRC-STONY-BROOK.ARPA>
Date: Fri, 26 Jul 85 14:49 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
As nearly as I can tell, Common Lisp offers no way to even clear the
screen.
It hurts me to see various sanded-edged parallelipipeds and egg-shaped
frobs being offered for the reinvention of the wheel.
Fine. I just assume NOT waste time re-inverting the wheel. I would
be perfectly happy if we copied verbatim the functional of the ITS TTY
code. Unfortunately there are problems with this. Some of which I
have alluded to in previous messages.
The main problem with ITS, in this respect, is that it is difficult to
tell it about new terminals. This is because the knowledge of each
supported terminal in embodied in assembly language code which many
users are afraid to touch. Now, given the ideocyncracies of various
terminals, there are clear advantages to this over any declarative
database like unix termcap. Furtunately we can do it in Lisp this
time around. Are there any ITS wizards who would like to write a
proposal for an ITS-style terminal system for Common Lisp? How about
you, Bernie?
Tim McNerney
∂29-Jul-85 1235 Fischer.pa@Xerox.ARPA RE: Clearing the screen and other such things.
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 12:34:34 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 29 JUL 85 12:33:27 PDT
Date: 29 Jul 85 12:30 PDT
From: Fischer.pa@Xerox.ARPA
Subject: RE: Clearing the screen and other such things.
To: Common-lisp@SU-AI.arpa
cc: CL-windows@SU-AI.arpa
Message-ID: <850729-123327-2607@Xerox>
Its pretty clear that the CL-Windows group became disheartened when it
was reported that ANSI was working on a standard. This may not be the
case. One can hope it was actually a mass defection to the ANSI group,
but I doubt that.
Perhaps now that the subjec thas been warmed up to, and since not much
seems to have solved the problem in the interim, perhaps we can get
someone to describe what the state of the various "standards committees"
are.
There were two mentioned just before the CL-Windows group closed its
shutters, one was a band of rowdy manufacturers (including Microsoft,
DRI, Intel, Apollo, Masscomp, Sun Micro Sys, Olivetti, Motorola, Nova
Graphics) the other of couse ANSI.
Can anyone comment immediately on the state of these committees to the
CL-windows@SU-AI.arpa mailing list?
(ron)
∂29-Jul-85 1752 Moon@SCRC-STONY-BROOK.ARPA Does READ-CHAR echo?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 17:52:32 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 284905; Mon 29-Jul-85 20:51:52-EDT
Date: Mon, 29 Jul 85 20:51 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Does READ-CHAR echo?
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>,
Robert W. Kerns <RWK@SCRC-YUKON.ARPA>,
Earl Killian <mips!earl@SU-GLACIER.ARPA>
cc: Common-Lisp@SU-AI.ARPA, CWH@SCRC-STONY-BROOK.ARPA
In-Reply-To: <850726150233.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<850726172130.7.RWK@CROW.SCRC.Symbolics.COM>,
<8507262313.AA24168@mips.UUCP>
Message-ID: <850729205156.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 26 Jul 85 15:02 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
I could not find any place in CLtL where it says whether READ-CHAR echos
the character that it has read. Likewise for PEEK-CHAR. Also, there is
no discussion of whether UNREAD-CHAR should unecho the character.
The manual says on page 328 that READ-CHAR from the terminal echos. I don't
know why this isn't repeated on page 379. The manual should say that
UNREAD-CHAR doesn't unecho characters; it implies it by saying that UNREAD-CHAR
is only for parsers and can only back up one character.
I note that Symbolics Common Lisp has (somewhat arbitrarily, I guess)
decided that READ-CHAR echos, PEEK-CHAR does not echo, and UNREAD-CHAR
does not un-echo the character.
PEEK-CHAR echos characters it eats, but not the one it leaves in the stream's
input buffer. Yes, the manual ought to say something about echoing in PEEK-CHAR.
This has the odd effect that:
(PROGN (PEEK-CHAR) (UNREAD-CHAR (READ-CHAR)) (READ-CHAR))
echos the character twice.
This is a bug in our operating system, not in Common Lisp. The problem is
that if instead you had written
(PROGN (PEEK-CHAR) (UNREAD-CHAR (READ-CHAR)) (PRINT 'FOO) (READ-CHAR))
then it really was supposed to echo it twice, once before the FOO and again
after it. It's somewhat difficult to fix your example without breaking this
one.
Does anyone have any thoughts about whether we should think about adding
functions called PEEK-CHAR-NO-ECHO, READ-CHAR-NO-ECHO, and UNREAD-CHAR-NO-ECHO?
Or maybe there should be WITH-INPUT-ECHO and WITHOUT-INPUT-ECHO special forms
which affect calls to the character readers within the dynamic scope of their
body.
I don't see anything about this in the manual, but I remember discussions of the
Common Lisp committee at which we decided that Common Lisp (first edition) wasn't
going to try to be a language you could write a display editor in. The problem
is that this quickly gets you mired in a host of operating-system dependencies.
We decided it was better to have to go outside the portable language to do the
terminal input and output sections of your display editor; of course all the
difficult parts could be written in Common Lisp.
In addition to the ways of reading one character of input with echoing you
suggested (different function, dynamically-scoped state), one should also
mention using a different stream, adding a fifth optional argument to READ-CHAR,
and providing functions to turn an echoing "mode" on and off. I can't guess which
implementors would have difficulty getting their operating system to conform to
which of these methods.
Date: Fri, 26 Jul 85 17:21 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
I think the only one needed would be READ-CHAR-NO-ECHO.
I agree.
[From: KMP]
I kind of assume that we all agree that READ and READ-LINE should echo
the characters as they come in from an interactive terminal. Perhaps,
we should state that explicitly in the next edition of the manual.
Page 328.
Date: Fri, 26 Jul 85 16:13:10 pdt
From: mips!earl@Glacier (Earl Killian)
Does READ-CHAR echo, or does the terminal handler, which supplied the
character in the first place, echo? Echoing is terminal-specific
(you don't want READ-CHAR from a file to echo) so it makes more sense
to talk about what the terminal handler does.
See the carefully evasive language on page 328.
This starts to get
into the controversy over whether you want to echo the character when
it is typed ("interrupt level") or when it is read, or try to rise
above these simple alternatives to do the right thing.
Here comes the morass of operating-system dependencies! In some systems these
concepts aren't even meaningful. In some others the implementor of Common Lisp
has no control over these affairs.
∂29-Jul-85 2307 DDYER@USC-ISIB.ARPA Clearing the screen etc.
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 23:07:02 PDT
Date: 29 Jul 1985 23:05:33 PDT
Subject: Clearing the screen etc.
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: common-lisp@SU-AI.ARPA
cc: cl-windows@SU-AI.ARPA
Symbolics has adopted "window" in place of "screen" in its
naming conventions. I think this is the right thing, and is
superior to both "screen" and "terminal" except possibly in cases
where the display operation really does refer to a screen
or a terminal.
Also, with respect to naming, let me plug my preference; rather
than add a lot of DO-THIS-OR-THAT functions, I'd rather add ONE
function, which encapsulates all screen operations. I have in mind
the general form;
(displayop <<displaystream>> <<operation>> &rest args)
This general form permits all "window" operations to be
recognized trivially, permits generic and implementation specific
extensions, and permits both "flavorized" and "macroized"
implementations. It also has the advantage of not polluting
the language with a lot more random function names.
The CL-WINDOWS mailing list (which I theoretically moderate)
is pretty moribund, mainly from the inability to sustain a
conversation. I have a feeling that each of the CL
implementations is pretty set in its own way of handling
displays, and the efficiency issues, combined with the
extremely low-level nature of display drivers, make any
compromise agreement on "standards" for fully elaborated
displays unlikely. As such, I support the idea of
chipping off this piece of the problem.
-------
∂30-Jul-85 0138 masinter.pa@Xerox.ARPA Re: CHAR-BIT
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 30 Jul 85 01:37:52 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 30 JUL 85 01:38:41 PDT
Date: 30 Jul 85 01:39 PDT
From: masinter.pa@Xerox.ARPA
Subject: Re: CHAR-BIT
In-reply-to: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>'s message of Fri,
26 Jul 85 14:02 EDT
To: KMP@SCRC-STONY-BROOK.ARPA
cc: COMMON-LISP@SU-AI.ARPA
Message-ID: <850730-013841-3371@Xerox>
The control bit isn't the same as what ASCII calls "control". It cannot
be, since control-A and control-a are defined to be distinct, yet those
are the same in ASCII.
Anything that purports to be a standard should avoid things of the
nature "implementations are free to ignore this". It just leads to a
false sense of portability. If you have code that relies on the
Coke-Bottle feature, it won't run or be particularly meaningful in code
that doesn't have Coke-Bottles. "Truthfully claim portability" is only
in name.
I think it makes sense to merge "bits" with "code" (since ASCII does
this anyway). Implementations that want to have more "bits" can define
them as extensions of the code space.
new:char-code-limit = (* old:char-code-limit old:char-bits-limit)
new:char-bits-limit = 1
(There's also a serious problems with fonts and font-numbers, and we've
abandoned them for Interlisp-D, but that's another story.)
∂30-Jul-85 0206 masinter.pa@Xerox.ARPA Re: Clearing the screen etc.
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 30 Jul 85 02:06:30 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 30 JUL 85 02:07:17 PDT
Date: 30 Jul 85 02:07 PDT
From: masinter.pa@Xerox.ARPA
Subject: Re: Clearing the screen etc.
In-reply-to: Dave Dyer <DDYER@USC-ISIB.ARPA>'s message of 29 Jul 85
23:05:33 PDT
To: DDYER@USC-ISIB.ARPA
cc: common-lisp@SU-AI.ARPA
Message-ID: <850730-020717-3379@Xerox>
Calling all of the display operation functions "displayop ...." doesn't
help any more than proclaiming that all display operations will be
symbols in the "display" package, does it?
I mean, if you want something to be Common and Portable then you have to
make choices. Deciding the form without the content is a non-choice.
∂30-Jul-85 0643 greek@DEC-HUDSON Terminal operations.
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 30 Jul 85 06:43:14 PDT
Date: Tue, 30 Jul 85 09:42:48 EDT
From: greek@DEC-HUDSON
Subject: Terminal operations.
To: common-lisp@su-ai
In fact, Symbolics' use of the term "window" is grossly at odds with
its use in the graphics literature, where a window is a (usually)
rectangular region in the world coordinate system which is of interest
to some function (e.g., one which displays it in a viewport on the screen).
I hope we all agree that Common LISP should use the accepted terms
when adding graphics to the language. The terms we use for the
"windowing" portion of the overall graphics facility must not conflict
with the terms in the remainder of the graphics facility. This is one
reason I wonder why there are two separate committees involved here.
I also object to the use of one GRAPHICSOP function. If we are going to
add graphics, then we must decide on the semantics first, then on
the function syntax. In particular, we could stipulate that all
graphics/windowing/text-display functions to in a separate package.
This would help some with the name conflict problem. (oops, that's
"go in a separate...")
Yes, we could wait until ANSII comes out with a standard. On the other
hand, if we're so worried about standards, why didn't we just adopt
an existing standard (e.g., GKS) in the first place?
- Paul
∂30-Jul-85 0756 RAM@CMU-CS-C.ARPA CHAR-BIT
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 30 Jul 85 07:56:44 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Tue 30 Jul 85 10:58:12-EDT
Date: Tue, 30 Jul 1985 10:58 EDT
Message-ID: <RAM.12131139233.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: masinter.pa@XEROX.ARPA
Cc: COMMON-LISP@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA
Subject: CHAR-BIT
In-reply-to: Msg of 30 Jul 1985 04:39-EDT from masinter.pa at Xerox.ARPA
I think that in the case of I/O (and thus characters) it makes a great
deal of sense to have language features which are optional. While it
is true that no program that counts on the existance of such a feature
is totally portable, there is at least an accepted way to describe how
the program is non-portable, and a canonical implementation if the
feature is implemented.
If I sit down at a J. Random & Co. Lisp machine and type
Control-Meta-Hyper-A, there is no guarantee that the obvious character
will be sent, but if it isn't the manufacturer is guilty of criminal
bogosity. It is true that if old J.R. didn't see fit to put the key
on his keyboard, then any program that counted on reading characters
with bits won't work too well, thus such a program is non-portable.
No program which contains any character that isn't standard-char-p is
portable, so implementors of portable programs must find some way to
factor out implementation-dependent information about characters.
Note that it is quite possible for a Common Lisp program (such as a
text editor) to do sensible things with character bits if they exist,
and ignore them if they don't. The text editor is still portable, it
is just the key bindings which are non-portable.
I see no advantage in merging bits and code. The fact that ASCII
merges information that would be better encoded as separate bits is
irrelevant; Common Lisp implementors have no obligation to perpetuate
ASCII bogosity.
I agree that the "font" support in Common Lisp is totally worthless.
Fortunately it is easy to ignore. It seems that what the "font"
information is really intended to represent is a facecode, e.g.
"bold", "italic", rather than an absolute font "timesroman10b". As
such, it would make more sense to have named character facecodes
instead of these silly numbers. Even so, this wouldn't be terribly
useful, since having some bits hung off of every character is a pretty
poor way to represent font information.
Rob
∂30-Jul-85 1209 MEEHAN@YALE.ARPA Re: Clearing the screen and other such things.
Received: from YALE.ARPA by SU-AI.ARPA with TCP; 30 Jul 85 12:09:37 PDT
Received: by YALE-BULLDOG.YALE.ARPA; 29 Jul 85 12:21:25 EDT (Mon)
Message-Id: <8507291621.AA10053@YALE-BULLDOG.YALE.ARPA>
Date: Mon, 29 Jul 85 10:57:46 EDT
From: Jim Meehan <Meehan@YALE.ARPA>
Subject: Re: Clearing the screen and other such things.
To: Kent M Pitman <KMP@SCRC-STONY-BROOK>
Cc: COMMON-LISP@SU-AI
In-Reply-To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>, Fri, 26 Jul 85 14:49 EDT
I'm afraid I agree with most of the criticism of your proposal. It
all sounds a little odd in an age where bitmaps and variable-width
fonts are so popular. The fact that you propose functions to erase
the character in front of the cursor and behind the cursor but not
*at* the cursor suggests that you yourself are accustomed to something
smarter than a glass teletype.
In any case, I wanted specifically to object to your use of VALUES:
... It should be possible to say
(SETF (CHARACTER-POSITION) (VALUES x y))
to later restore the cursor to the given coordinates.
VALUES is an "upward only" construction, and special forms
notwithstanding, you're trying to pass multiple values to the "setter"
of CHARACTER-POSITION. Granted, VALUES is asymmetric, and
(MULTIPLE-VALUE-CALL SET-CHARACTER-POSITION (VALUES x y)) is uglier,
but VALUES in CL is a first attempt at providing a notation for passing
values to the continuation of the caller, not a substitute for CONS.
-------
∂30-Jul-85 2034 RWK@SCRC-STONY-BROOK.ARPA Terminal operations.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 30 Jul 85 20:34:00 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 286025; Tue 30-Jul-85 21:09:40-EDT
Date: Tue, 30 Jul 85 21:10 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Terminal operations.
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 30 Jul 85 09:42-EDT from greek@DEC-HUDSON
Message-ID: <850730211028.5.RWK@CROW.SCRC.Symbolics.COM>
Date: Tue, 30 Jul 85 09:42 EDT
From: greek@DEC-HUDSON
In fact, Symbolics' use of the term "window" is grossly at odds with
its use in the graphics literature, where a window is a (usually)
rectangular region in the world coordinate system which is of interest
to some function (e.g., one which displays it in a viewport on the screen).
I hope we all agree that Common LISP should use the accepted terms
when adding graphics to the language. The terms we use for the
"windowing" portion of the overall graphics facility must not conflict
with the terms in the remainder of the graphics facility.
The concept of windows does not come from the hard-core graphics
community, it comes out of the research into user-interfaces and
workstations. I don't see why the graphics terminology should be
considered any more "accepted". Certainly Symbolics did not invent
the term "window" as we use it.
This is one
reason I wonder why there are two separate committees involved here.
Because the concept of managing your screen real-estate between
different processes and interactions has very little in common
with protocols for drawing pictures and repesenting graphics.
About the only thing they have in common is the use of the word
"window" and that they make good use of bit-map screens.
We do have to address issues like "what do we do with the word
window", but the solution isn't just to declare one usage
"non-standard". Personally, I don't find it confusing to talk
about "A window running Lisp" vs "A window into a large diagram".
In some sense, they're the same thing, but are connected into
their respective universes differently. I think we can come up
with a definition which will satisfy both camps.
∂31-Jul-85 1107 DCP@SCRC-STONY-BROOK.ARPA Clearing the screen and other such things.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 31 Jul 85 11:07:23 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 286563; Wed 31-Jul-85 13:12:04-EDT
Date: Wed, 31 Jul 85 13:13 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Clearing the screen and other such things.
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>,
Earl Killian <mips!earl@SU-GLACIER.ARPA>,
Tim McNerney <TIM@MIT-MC.ARPA>,
Richard Fateman <fateman%ucbdali@UCB-VAX.ARPA>,
Skef Wholey <Wholey@CMU-CS-C.ARPA>,
Rob MacLachlan <RAM@CMU-CS-C.ARPA>,
Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>,
Guy Steele <gls@THINK-AQUINAS.ARPA>, COMMON-LISP@SU-AI.ARPA,
KMP@SCRC-STONY-BROOK.ARPA, fateman@UCBDALI.ARPA
In-Reply-To: <850726144908.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<8507262335.AA25005@mips.UUCP>,
<[MIT-MC.ARPA].590150.850727.TIM>,
<8507271838.AA20272@ucbdali.ARPA>,
<[MIT-MC.ARPA].590458.850727.TIM>,
<WHOLEY.12130497295.BABYL@CMU-CS-C.ARPA>,
<RAM.12130686608.BABYL@CMU-CS-C.ARPA>,
<[MIT-MC.ARPA].591637.850729.TIM>,
<RAM.12130807766.BABYL@CMU-CS-C.ARPA>,
<850729090643.0.BSG@CONCORD.SCRC.Symbolics.COM>,
<850729125323.3.GLS@POLYCARP.ARPA>,
<[MIT-MC.ARPA].592267.850729.TIM>
Message-ID: <850731131314.2.NFEP@NEPONSET.SCRC.Symbolics.COM>
I am tempted to propose that there be a "font" whose character codes
range from 0 to #o377, and are interpreted according to the SUPDUP and
SUPDUP Graphics protocol. There would be some function which returns
the 400 or so bits of state the describe the terminal. If nothing else,
this will give people something generic to use in the n>2 years it will
take to agree on something more powerful.
[This is 75% serious, modulo the rough edges. I've dealt with SUPDUP
quite a bit in the past and will right up a 80% complete proposal if
there is enough interest.]
∂05-Aug-85 0938 KESSLER@UTAH-20.ARPA Lambda Keywords
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 5 Aug 85 09:38:24 PDT
Date: Mon 5 Aug 85 10:38:22-MDT
From: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
Subject: Lambda Keywords
To: common-lisp@SU-AI.ARPA
I can't remember if this was discussed already or not, but:
Should lambda keywords be installed in the keyword package (i.e.
& is some how similar to :)?
Bob.
-------
∂05-Aug-85 1010 FAHLMAN@CMU-CS-C.ARPA Lambda Keywords
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Aug 85 10:10:28 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 5 Aug 85 13:12:27-EDT
Date: Mon, 5 Aug 1985 13:12 EDT
Message-ID: <FAHLMAN.12132736552.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "Robert R. Kessler" <KESSLER@UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Lambda Keywords
In-reply-to: Msg of 5 Aug 1985 12:38-EDT from Robert R. Kessler <KESSLER at UTAH-20.ARPA>
No, the &foo symbols reside in the LISP package, from which almost
every other package can inherit them without qualifiers.
-- Scott
∂06-Aug-85 1356 Bobrow.pa@Xerox.ARPA defstruct syntax
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 6 Aug 85 13:56:36 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 06 AUG 85 13:53:54 PDT
Date: 6 Aug 85 13:50 PDT
From: Bobrow.pa@Xerox.ARPA
Subject: defstruct syntax
To: common-lisp@su-ai.ARPA
Message-ID: <850806-135354-1018@Xerox>
On page 307 defstruct syntax is defined as
defstruct name-and-options [doc-string] {slot-description}+
we believe it should be
defstruct name-and-options [doc-string] {slot-description}*
since it is perfectly reasonable to have
(defstruct (foo (:include bar (x 33))))
to make foo be like bar but have a different initial value for x.
ken kahn & danny bobrow
∂06-Aug-85 1421 gls@THINK-AQUINAS.ARPA defstruct syntax
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 Aug 85 14:20:54 PDT
Received: from faustinas by GODOT.THINK.COM via CHAOS; Tue, 6 Aug 85 17:21:30 edt
Date: Tue, 6 Aug 85 17:20 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: defstruct syntax
To: Bobrow.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <850806-135354-1018@Xerox>
Message-Id: <850806172053.6.GLS@FAUSTINUS.THINK.COM>
Date: 6 Aug 85 13:50 PDT
From: Bobrow.pa@Xerox.ARPA
On page 307 defstruct syntax is defined as
defstruct name-and-options [doc-string] {slot-description}+
we believe it should be
defstruct name-and-options [doc-string] {slot-description}*
since it is perfectly reasonable to have
(defstruct (foo (:include bar (x 33))))
to make foo be like bar but have a different initial value for x.
ken kahn & danny bobrow
I agree. I should have known. "+" is almost never the right thing
compared with "*".
--Guy
∂07-Aug-85 1155 WHOLEY@CMU-CS-C.ARPA CLTL tablos and indexos (not really typos)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 Aug 85 11:55:12 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Wed 7 Aug 85 14:43:49-EDT
Date: Wed, 7 Aug 1985 14:43 EDT
Message-ID: <WHOLEY.12133277369.BABYL@CMU-CS-C.ARPA>
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Common-Lisp@SU-AI.ARPA
Subject: CLTL tablos and indexos (not really typos)
The symbols Unsigned-Byte and Mod are not listed in the table of "standard type
specifier symbols" on page 43 of CLTL. These symbols are described on pages 48
and 49 as type specifiers, however. Neither is listed in the index as a type
specifier (although both have references to Open for the :element-type keyword
argument). In fact, no type specifier symbols are listed as such in the index.
All this was confusing to a new Common Lisp programmer who was trying to
understand an existing Common Lisp program.
--Skef
∂07-Aug-85 1944 KSH@MIT-MC.ARPA
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 Aug 85 19:44:15 PDT
Date: Wed, 7 Aug 85 22:45:47 EDT
From: Kjeld Hvatum <KSH@MIT-MC.ARPA>
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].604537.850807.KSH>
FROM: BACHER, STEPHEN E. SENT ON: 07/01/85 AT 08:04 DATE - 07/01/85
Reply to CL flame on disallowing NIL as a feature:
If you make it an error (signalled or otherwise) for NIL to be a
feature, then an awful lot of Macsyma source code will break, for
NIL (the language, that is) is used as a feature name throughout
in #+/#- conditionals.
∂08-Aug-85 0714 KMP@SCRC-STONY-BROOK.ARPA Disallowing NIL as a feature
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Aug 85 07:14:12 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 291294; Thu 8-Aug-85 10:14:31-EDT
Date: Thu, 8 Aug 85 10:14 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Disallowing NIL as a feature
To: KSH@MIT-MC.ARPA
cc: Common-Lisp@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA
In-Reply-To: <[MIT-MC.ARPA].604537.850807.KSH>
Message-ID: <850808101436.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Wed, 7 Aug 85 22:45:47 EDT
From: Kjeld Hvatum <KSH@MIT-MC.ARPA>
FROM: BACHER, STEPHEN E. SENT ON: 07/01/85 AT 08:04 DATE - 07/01/85
Reply to CL flame on disallowing NIL as a feature:
If you make it an error (signalled or otherwise) for NIL to be a
feature, then an awful lot of Macsyma source code will break, for
NIL (the language, that is) is used as a feature name throughout
in #+/#- conditionals.
Since it's been proposed that features be defaultly read in the keyword package
and since :NIL is not what's under discussion, this probably doesn't affect
Macsyma. Presumably you'd have to type #+LISP:NIL to get the problemsome case,
and I don't think anyone does that.
Even if we didn't defaultly read features in the keyword package, I am the one
who originally suggested disallowing NIL as a feature name and I also happen to
maintain the Macsyma sources for Symbolics and I can assure you that if such a
change ever "broke" Macsyma, then it could be easily be fixed in less than 15
minutes using Tags Query Replace.
Let's try to distinguish between the situation of something being affected by
a change and something being broken by a change.
-kmp
∂12-Aug-85 1551 Masinter.pa@Xerox.ARPA CommonLoops: Merging Common Lisp Object-Oriented Programming
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 12 Aug 85 15:51:06 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 12 AUG 85 15:52:20 PDT
Date: 12 Aug 85 15:53 PDT
From: Masinter.pa@Xerox.ARPA
Subject: CommonLoops: Merging Common Lisp Object-Oriented Programming
To: Common-Lisp@SU-AI.ARPA, Info-1100@Sumex-aim.ARPA
Reply-to: MGardner.PA@Xerox.ARPA
Message-ID: <850812-155220-3348@Xerox>
CommonLoops is is a merger of object-oriented programming and Lisp. We
are proposing that it be adopted as a standard within the Common Lisp.
We have written a paper about CommonLoops, which we are distributing to
members of the Common Lisp Object-Oriented Programming group for
discussion at a meeting during IJCAI.
If you would like a copy of the paper, please send your name and
complete address to Mimi Gardner (MGardner.PA@Xerox). (Copies have been
distributed to members of CL-Object-Oriented-Programming).
There is a discussion list, CommonLoops↑.PA@XEROX, for discussions about
technical issues. This discussion group is open, and currently includes
members both from within and outside of Xerox. If you wish to be
included, please reply.
ABSTRACT
Object oriented programming has long been recognized as a key
programming technique for many applications. CommonLoops blends object
oriented programming harmoniously with the function oriented design of
Lisp. In CommonLoops, Lisp functions are methods, Lisp data types are
classes, and message passing is invoked via normal Lisp function call;
programs can incrementally be moved between the functional and
object-oriented style. CommonLoops has a small kernel, yet it is
powerful enough to be a base for implementing the features of the major
object-oriented systems in use today. Through the use of metaclasses,
multiple paradigms can gracefully coexist. Thus, CommonLoops provides
the basic mechanism of object oriented programming as an extension to
Common Lisp, while allowing a wide variety of experimentation with
different styles of using it. Over the next few months, we expect the
this design to profit greatly from the discussions of the community.
∂13-Aug-85 1240 SQUIRES@USC-ISI.ARPA Re: CommonLoops: Merging Common Lisp Object-Oriented Program...
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 13 Aug 85 12:40:48 PDT
Date: 13 Aug 1985 15:39-EDT
Sender: SQUIRES@USC-ISI.ARPA
Subject: Re: CommonLoops: Merging Common Lisp Object-Oriented Program...
From: Stephen L. Squires <SQUIRES@USC-ISI.ARPA>
To: MGardner.PA@XEROX.ARPA
Cc: Common-Lisp@SU-AI.ARPA, Info-1100@SUMEX-AIM.ARPA
Message-ID: <[USC-ISI.ARPA]13-Aug-85 15:39:47.SQUIRES>
In-Reply-To: <850812-155220-3348@Xerox>
Please send a copy of the report. I would also like to know when it
will be in a form that we could try it out.
Stephen L. Squires
DARPA/IPTO
Assistant Director
1400 Wilson Blvd
Arlington, VA 22209
∂15-Aug-85 1518 nmm%computer-lab.cambridge.ac.uk@ucl-cs.ARPA
Received: from UCL-CS.ARPA by SU-AI.ARPA with TCP; 15 Aug 85 15:17:56 PDT
Received: from computer-lab.cambridge.ac.uk by 44d.Cs.Ucl.AC.UK
via Janet with NIFTP id a001101; 15 Aug 85 23:15 BST
Date: Thu, 15 Aug 85 23:08:19 bst
From: Nick Maclaren <nmm%computer-lab.cambridge.ac.uk@ucl-cs.arpa>
Message-Id: <8508152208.AA09181@UK.AC.cam.cl>
To: Common-Lisp@su-ai.arpa
Does anyone know of anyone who is producing a Common Lisp (especially
a Spice Lisp port) for IBM machines? We are interested in versions that
will be available either with proper support and maintenance or as
source in a working state. We are prepared to convert from any other
370-series operating system to ours (MVS), if the program is sufficiently
well-suited for such conversion; this includes Amdahl UNIX. Thanks for
any information.
Nick Maclaren
University of Cambridge Computer Laboratory
Try replying to: nmm%uk.ac.cam.cl@ucl-cs.arpa
∂16-Aug-85 0056 franz!jkf@Berkeley endp or not consp
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 16 Aug 85 00:56:32 PDT
Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/5.3)
id AA28468; Fri, 16 Aug 85 00:57:56 pdt
Received: by ucbkim.ARPA (5.5/5.3)
id AA03790; Fri, 16 Aug 85 00:58:06 PDT
Received: by franz.uucp (1.2/3.14)
id AA02318; Thu, 8 Aug 85 07:13:12 pdt
Date: Thu, 8 Aug 85 07:13:12 pdt
From: franz!jkf@Berkeley (John Foderaro)
Message-Id: <8508081413.AA02318@franz.uucp>
To: common-lisp@su-ai
Subject: endp or not consp
Cc:
On page 27 the book defines the terms 'list', 'true list' and 'dotted list',
and states that most functions that expect a 'list' expect a 'true list',
not a 'dotted list'. Does someone have a list (true or dotted) of precisely
which functions expect and 'true list' and which will take a 'dotted list'?
Only because of an example on page 267 do we learn that 'last' can
take a 'dotted list'.
-john foderaro
∂16-Aug-85 1200 robbins@DEC-HUDSON with-output-to-string query
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 16 Aug 85 12:00:08 PDT
Date: Fri, 16 Aug 85 14:59:35 EDT
From: robbins@DEC-HUDSON
Subject: with-output-to-string query
To: common-lisp@su-ai
The definition of WITH-OUTPUT-TO-STRING given in the Common Lisp
reference manual states that:
"If string is specified ... the output is incrementally appended to the
string, as if using VECTOR-PUSH-EXTEND if the string is adjustable, and
otherwise as if using VECTOR-PUSH."
This implies that after a non-adjustable output string is "filled" any
extra characters output to it will simply be dropped and no error will
be signalled. Is this correct?
-- Rich Robbins
∂16-Aug-85 1240 FAHLMAN@CMU-CS-C.ARPA with-output-to-string query
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 16 Aug 85 12:40:38 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 16 Aug 85 15:41:26-EDT
Date: Fri, 16 Aug 1985 15:41 EDT
Message-ID: <FAHLMAN.12135647246.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: robbins@DEC-HUDSON.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: with-output-to-string query
In-reply-to: Msg of 16 Aug 1985 14:59-EDT from robbins at DEC-HUDSON
The definition of WITH-OUTPUT-TO-STRING given in the Common Lisp
reference manual states that:
"If string is specified ... the output is incrementally appended to the
string, as if using VECTOR-PUSH-EXTEND if the string is adjustable, and
otherwise as if using VECTOR-PUSH."
This implies that after a non-adjustable output string is "filled" any
extra characters output to it will simply be dropped and no error will
be signalled. Is this correct?
Yeah, given that VECTOR-PUSH is documented not to complain when a
non-adjustable string overflows, it seems to follow that
WITH-OUTPUT-TO-STRING should just ignore excess output in this case and
not signal an error. This seems like a treacherous mechanism that could
screw the unwary, but in the vast majoirty of cases users will let the
system create the string or will use an adjustable one if this meant to
implement some sort of non-consing buffer.
I'm not sure why we decided that VECTOR-PUSH should fail silently, but
we must have had some good reason at the time. Probably we just copied
Zetalisp and THEY had a good reason.
-- Scott
∂16-Aug-85 1505 RPG
"bkb%computer-lab.cambridge.ac.uk"@ucl-cs
Varia
The bulletin board is actually a mailing list - it is not digested. All Common
Lisp mail is in the files
COMMON.1[COM,LSP]
COMMON.2[COM,LSP]
COMMON.3[COM,LSP]
COMMON.4[COM,LSP]
COMMON.MSG[COM,LSP]
These files are in reverse chronological order (most recent last), and
no one login is required to FTP them away.
I have put you on the Common Lisp mailing list.
-rpg-
∂16-Aug-85 1505 RPG Common Lisp Bill Board
∂13-Aug-85 1718 bkb%computer-lab.cambridge.ac.uk@ucl-cs.ARPA Common Lisp Bill Board
Received: from UCL-CS.ARPA by SU-AI.ARPA with TCP; 13 Aug 85 17:17:49 PDT
Received: from computer-lab.cambridge.ac.uk by 44d.Cs.Ucl.AC.UK
via Janet with NIFTP id a000175; 13 Aug 85 11:47 BST
Date: Tue, 13 Aug 85 11:30 BST
From: Bran Boguraev <bkb%computer-lab.cambridge.ac.uk@ucl-cs.arpa>
To: RPG <RPG%su-ai.arpa@ucl-cs.arpa>
Subject: Common Lisp Bill Board
Message-Id: <85/08/13 11:30.520 bkb@jenny>
I understand that you administer (?) a Common Lisp bill-board, as well as keep
back issues of it somewhere at SAIL. I would like to subscribe to it, as well
as browse through the back issues... Can you add me to the mailing list, or
point me at the BB administrator?
Thanks,
Bran Boguraev
University of Cambridge
Computer Laboratory
Corn Exchange Street
Cambridge, UK
"bkb%computer-lab.cambridge.ac.uk"@ucl-cs
Varia
The bulletin board is actually a mailing list - it is not digested. All Common
Lisp mail is in the files
COMMON.1[COM,LSP]
COMMON.2[COM,LSP]
COMMON.3[COM,LSP]
COMMON.4[COM,LSP]
COMMON.MSG[COM,LSP]
These files are in reverse chronological order (most recent last), and
no one login is required to FTP them away.
I have put you on the Common Lisp mailing list.
-rpg-
∂16-Aug-85 1536 RPG Greetings
To: common-lisp@SU-AI.ARPA
As I have observed, we have all had a productive year in implementing
and thinking about Common Lisp. The various subcommittees have been
busily considering issues of interest to the Common Lisp community.
It has been nearly a year since the Monterey meeting, and DARPA feels that
it is time for a second meeting. At this meeting, I think it
is possible to settle matters in the following areas:
Charter
Validation
I think we can make great headway in these areas:
Object Oriented Programming
Error Handling
I think concerns can be aired in the remaining areas.
After some thought, it seems that the East Coast in late October
or mid-November is a good time. Comments as to exact dates and
a location would be appreciated.
-rpg-
∂18-Aug-85 1159 Moon@SCRC-STONY-BROOK.ARPA with-output-to-string query
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Aug 85 11:59:02 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 298206; Sun 18-Aug-85 14:58:44-EDT
Date: Sun, 18 Aug 85 14:59 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: with-output-to-string query
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: robbins@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12135647246.BABYL@CMU-CS-C.ARPA>
Message-ID: <850818145935.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 16 Aug 1985 15:41 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
The definition of WITH-OUTPUT-TO-STRING given in the Common Lisp
reference manual states that:
"If string is specified ... the output is incrementally appended to the
string, as if using VECTOR-PUSH-EXTEND if the string is adjustable, and
otherwise as if using VECTOR-PUSH."
This implies that after a non-adjustable output string is "filled" any
extra characters output to it will simply be dropped and no error will
be signalled. Is this correct?
Yeah, given that VECTOR-PUSH is documented not to complain when a
non-adjustable string overflows, it seems to follow that
WITH-OUTPUT-TO-STRING should just ignore excess output in this case and
not signal an error. This seems like a treacherous mechanism that could
screw the unwary, but in the vast majoirty of cases users will let the
system create the string or will use an adjustable one if this meant to
implement some sort of non-consing buffer.
I'm not sure why we decided that VECTOR-PUSH should fail silently, but
we must have had some good reason at the time. Probably we just copied
Zetalisp and THEY had a good reason.
VECTOR-PUSH doesn't fail silently, it returns a value to say whether or not
it was able to store into the vector. I don't remember why this Zetalisp design
decision, made in 1974 or 1975, was done this way. Actually I wasn't around then.
It seems clear to me that no one intended WITH-OUTPUT-TO-STRING to throw away
characters if given a non-adjustable string to fill. Since it can't return
a value to say whether it filled the string, it should signal an error. I
think this is just looseness in the manual, not a real language issue. If
someone else disagrees they should speak up!
∂18-Aug-85 1519 FAHLMAN@CMU-CS-C.ARPA with-output-to-string query
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 Aug 85 15:19:05 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 18 Aug 85 18:20:02-EDT
Date: Sun, 18 Aug 1985 18:19 EDT
Message-ID: <FAHLMAN.12136200411.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: with-output-to-string query
In-reply-to: Msg of 18 Aug 1985 14:59-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
It seems clear to me that no one intended WITH-OUTPUT-TO-STRING to throw away
characters if given a non-adjustable string to fill. Since it can't return
a value to say whether it filled the string, it should signal an error. I
think this is just looseness in the manual, not a real language issue. If
someone else disagrees they should speak up!
I agree that it would be preferable in this case to signal an error --
as I said in my earlier note, it is rather treacherous to just discard
charaters without warning. However, the curent text of the manual seems
to say more or less clearly (though by indirection thropugh Vector-Push)
that no error is signalled in this case, so to "clarify" the manual as
Moon suggests is really a change, though one in a corner so obscure that
it wouldn't bother people too much. Perhaps the best resolution is for
now to say that "it is an error" to overflow the string being written,
and to change this to "signals an error" in Common Lisp 86 (or
whenever).
-- Scott
∂19-Aug-85 1104 Moon@SCRC-STONY-BROOK.ARPA with-output-to-string query
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 19 Aug 85 11:04:34 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 298471; Mon 19-Aug-85 12:56:04-EDT
Date: Mon, 19 Aug 85 12:57 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: with-output-to-string query
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12136200411.BABYL@CMU-CS-C.ARPA>
Message-ID: <850819125712.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 18 Aug 1985 18:19 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
It seems clear to me that no one intended WITH-OUTPUT-TO-STRING to throw away
characters if given a non-adjustable string to fill. Since it can't return
a value to say whether it filled the string, it should signal an error. I
think this is just looseness in the manual, not a real language issue. If
someone else disagrees they should speak up!
I agree that it would be preferable in this case to signal an error --
as I said in my earlier note, it is rather treacherous to just discard
charaters without warning. However, the curent text of the manual seems
to say more or less clearly (though by indirection thropugh Vector-Push)
that no error is signalled in this case
I don't see this implication in the text. The only thing that is clear is
that it says the output is appended to the string.
This is getting awfully rabbinical!
, so to "clarify" the manual as
Moon suggests is really a change, though one in a corner so obscure that
it wouldn't bother people too much. Perhaps the best resolution is for
now to say that "it is an error" to overflow the string being written,
and to change this to "signals an error" in Common Lisp 86 (or
whenever).
Or leave it "is an error" for all time, allowing individual implementations
to choose between safety, efficiency, and compatible with past broken
implementations. That seems like the best resolution to me.
Of course no matter what the resolution, it doesn't affect my implementation,
since all strings are adjustable, so I'm happy.
∂19-Aug-85 2350 TIM@MIT-MC.ARPA Side effecting constants inside functions
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 Aug 85 23:50:44 PDT
Date: Tue, 20 Aug 85 02:52:22 EDT
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject: Side effecting constants inside functions
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].618598.850820.TIM>
In CLtL, I can't find any mention of the issue of side effecting
internal constants. In Maclisp, NIL, Zetalisp, and presumably most
Common Lisp implementations, the function:
(defun withdraw (amount)
(let ((balance '(1000)))
(decf (first balance) amount)))
acts much like a lexical closure with a local state variable.
Thus, (withdraw 100) => 900, then (withdraw 100) => 800, etc. This
behaviour has always bothered me. Is this rather questionable style
condoned by Common Lisp?
Efficiency aside, it would be cleaner for the semantics of a function
which side effects its internal constants to be as though a fresh copy
were made each time the function was evaluated, effectively making
'(1000) == (list 1000) and #(1 2 3) == (vector 1 2 3), etc. This way,
the above function would always return 900.
If such a function is to behave as it does in Maclisp, there is a subtle
issue having to do with the interaction between the interpreter and the
compiler: Should COMPILE reset the local state of such a function?
(In NIL and Zetalisp it doesn't, but one can imagine that a "digested"
copy of the original lambda expression might be cached by the interpreter,
and that the compiler uses the original unscathed version).
Tim McNerney
∂20-Aug-85 0049 GSB@MIT-MC.ARPA Side effecting constants inside functions
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 20 Aug 85 00:49:39 PDT
Date: Tue, 20 Aug 85 03:51:17 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: Side effecting constants inside functions
To: TIM@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].618692.850820.GSB>
Date: Tue, 20 Aug 85 02:52:22 EDT
From: Tim McNerney <TIM@MIT-MC.ARPA>
In CLtL, I can't find any mention of the issue of side effecting
internal constants. In Maclisp, NIL, Zetalisp, and presumably most
Common Lisp implementations, the function:
(defun withdraw (amount)
(let ((balance '(1000)))
(decf (first balance) amount)))
acts much like a lexical closure with a local state variable.
Thus, (withdraw 100) => 900, then (withdraw 100) => 800, etc. This
behaviour has always bothered me. Is this rather questionable style
condoned by Common Lisp?
This extremely questionable style is considered "an error" in both Maclisp
and NIL, which take the view that such constants are permissible to be made
read-only, and potentially made EQ to other constants which are EQUAL.
Efficiency aside, it would be cleaner for the semantics of a function
which side effects its internal constants to be as though a fresh copy
were made each time the function was evaluated, effectively making
'(1000) == (list 1000) and #(1 2 3) == (vector 1 2 3), etc. This way,
the above function would always return 900.
Please take 2000 mg of Thorazine, and 10 mg cogentin to counteract the
smooth muscle contractions which might ensue. This might help to reduce
the level of distortion in your perception.
If such a function is to behave as it does in Maclisp, there is a subtle
issue having to do with the interaction between the interpreter and the
compiler: Should COMPILE reset the local state of such a function?
(In NIL and Zetalisp it doesn't, but one can imagine that a "digested"
copy of the original lambda expression might be cached by the interpreter,
and that the compiler uses the original unscathed version).
In a standard Maclisp scenario of loading compiled code, purifying and dumping
the environment, this does not work. In NIL when the code is compiled this
does not work, as such constants in compiled code in NIL are cuurently ALWAYS
read-only. If i interpret "reset the local state of such a function"
correctly, NIL always does so, since currently the in-core compilatioin is
only a kludge of to-file compilation so no datastructure gets preserved.
Otherwise, NIL never bashes anything, and such things as cached macro
expansions performed by the interpreter have absolutely no effect on the
expansions performed by the compiler.
Timothy Leary
Glenn S. Burnout
p.s. I have a manic-depressive friend who, while i haven't seen him
in a number of years, i can probably track down if given a few hours.
He would no doubt have a good supply of thorazine, cogentin, and
lithium on hand.
∂21-Aug-85 1057 robbins@DEC-HUDSON close queries
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 21 Aug 85 10:56:45 PDT
Date: Wed, 21 Aug 85 13:59:15 EDT
From: robbins@DEC-HUDSON
Subject: close queries
To: common-lisp@su-ai
What is supposed to happen when an attempt is made to close a synonym stream?
The manual seems to indicate that it is the stream which is bound to the
synonym symbol that should be closed, but, I am not sure that this is the
most desirable behaviour. What about someone that desires to close the
synonym stream but not the stream bound to the synonym symbol?
Is it an error to close *terminal-io*?
-- Rich Robbins
∂25-Aug-85 0015 TIM@MIT-MC.ARPA Side effecting constants inside functions
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 25 Aug 85 00:15:48 PDT
Date: Sun, 25 Aug 85 03:15:02 EDT
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject: Side effecting constants inside functions
To: GSB@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Tue 20 Aug 85 03:51:17 EDT from Glenn S. Burke <GSB at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].623486.850825.TIM>
Date: Tue, 20 Aug 85 03:51:17 EDT
From: Glenn S. Burke <GSB at MIT-MC.ARPA>
Date: Tue, 20 Aug 85 02:52:22 EDT
From: Tim McNerney <TIM@MIT-MC.ARPA>
In CLtL, I can't find any mention of the issue of side effecting
internal constants. In Maclisp [interpreted code], NIL, Zetalisp
[both interpreted and compiled code], and presumably most Common
Lisp implementations, the function:
(defun withdraw (amount)
(let ((balance '(1000)))
(decf (first balance) amount)))
acts much like a lexical closure with a local state variable.
Thus, (withdraw 100) => 900, then (withdraw 100) => 800, etc. This
behaviour has always bothered me. Is this rather questionable style
condoned by Common Lisp?
This extremely questionable style is considered "an error" in both
Maclisp and NIL, which take the view that such constants are
permissible to be made read-only, and potentially made EQ to other
constants which are EQUAL.
This would be a good position for Common Lisp to take, my point being that
this is not written down anywhere (not even in the NIL manual). The rest
of my letter merely supports this position by pointing out some issues that
would have to be dealt with if this were NOT considered an error. Perhaps
I did not make myself sufficiently clear.
Tim McNerney
P.S...
In NIL when the code is compiled this does not work, as such
constants in compiled code in NIL are currently ALWAYS read-only...
Glenn S. Burnout
Had you actually compiled the above function and tried it out, you would
have noticed that the NIL compiler produces code with exactly the same
behavior as Zetalisp, and furthermore, that the bogus state variable is,
despite your claims, preserved across COMPILE.
∂26-Aug-85 0737 Hornig@SCRC-STONY-BROOK.ARPA Side effecting constants inside functions
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Aug 85 07:37:01 PDT
Received: from HUDSON.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 301214; Mon 26-Aug-85 10:36:18-EDT
Date: Mon, 26 Aug 85 10:36 EDT
From: Charles Hornig <Hornig@SCRC-STONY-BROOK.ARPA>
Subject: Side effecting constants inside functions
To: Tim McNerney <TIM@MIT-MC.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <[MIT-MC.ARPA].618598.850820.TIM>
Message-ID: <850826103633.1.HORNIG@HUDSON.SCRC.Symbolics.COM>
Date: Tue, 20 Aug 85 02:52:22 EDT
From: Tim McNerney <TIM@MIT-MC.ARPA>
In CLtL, I can't find any mention of the issue of side effecting
internal constants. In Maclisp, NIL, Zetalisp, and presumably most
Common Lisp implementations, the function:
(defun withdraw (amount)
(let ((balance '(1000)))
(decf (first balance) amount)))
acts much like a lexical closure with a local state variable.
Thus, (withdraw 100) => 900, then (withdraw 100) => 800, etc. This
behaviour has always bothered me. Is this rather questionable style
condoned by Common Lisp?
We consider the fact that this "works" in Symbolics-Lisp (nee Zetalisp)
a deficiency which we intend to remedy now that our VM system can handle
read-only areas. I would certainly hope that no one would depend on
this working. (Faint hope, from talking to people at IJCAI.)
∂30-Aug-85 1411 @MIT-MC.ARPA:cfry@MIT-OZ put me on mailing list
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 30 Aug 85 14:10:41 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 28 AUG 85 23:03:39 EDT
Received: from MIT-DUANE by MIT-OZ via Chaosnet; 28 Aug 85 23:03-EDT
Date: Wed, 28 Aug 85 23:03 EDT
From: Christopher Fry <cfry@OZ>
Subject: put me on mailing list
To: common-lisp@OZ
Message-ID: <850828230313.2.CFRY@DUANE>
Please put me on the common lisp mailing list.
Is there an archive of previous messages?
∂30-Aug-85 1938 IMSSS@SUMEX-AIM.ARPA Re: close queries
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 30 Aug 85 19:38:12 PDT
Date: Fri 30 Aug 85 19:37:27-PDT
From: System-Assoc Dir <IMSSS@SUMEX-AIM.ARPA>
Subject: Re: close queries
To: robbins@DEC-HUDSON.ARPA
cc: IMSSS@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: Message from "robbins@DEC-HUDSON" of Wed 21 Aug 85 11:18:49-PDT
Message-ID: <12139393016.27.IMSSS@SUMEX-AIM.ARPA>
To close a synonym stream without closing the underlying stream,
you could reset the mediating symbol to point at a closed stream.
This is less than adequate for the general case, but might suggest
some mechanism that would work generally. (One problem of course
is that you may still want to access the name, etc., of the closed
stream.) I'm inclined to argue that the underlying stream should
not be closed, simply to give the user finer control.
jim mcdonald
-------
∂31-Aug-85 0617 MLY@MIT-MC.ARPA lexical madness
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 31 Aug 85 06:17:15 PDT
Date: Sat, 31 Aug 85 09:16:45 EDT
From: Richard Mlynarik <MLY@MIT-MC.ARPA>
Subject: lexical madness
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].629495.850831.MLY>
The definition of psetf specifies that the evaluations are performed
from left to right, but specifies that "all the assignments are
performed in an unpredicatable order"
There is, however, nothing said about the order in which `let' bindings
are made, only that "all the variables ... are bound to the
corresponding values in parallel"
So, to what should "(let ((x 1) (x 2)) x)" evaluate?
Other lacks of insight from the latest descent into Interpreted Hell:
* Was anything definitive resolved about the pervasiveness of
(not)inline and ftype declarations in the presence of flet and labels?
* I assume that
"(let* ((x 1)
(x (1+ (symbol-value 'x))))
(declare (special x))
x)"
evaluates to 2 (ie the special declaration applies to all bindings)
The same goes for multiply-bound variables in lambda-lists.
Next week: confessions of a wimplementor..
∂31-Aug-85 1450 edsel!eb@Navajo New constants needed
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 31 Aug 85 14:50:24 PDT
Received: by edsel.uucp (2.0/SMI-2.0)
id AA07008; Sat, 31 Aug 85 14:45:38 pdt
Date: Sat, 31 Aug 85 14:45:38 pdt
From: edsel!eb@Navajo (Eric Benson)
Message-Id: <8508312145.AA07008@edsel.uucp>
To: navajo!Common-Lisp@SAIL
Subject: New constants needed
I suggest adding the following defined constants to the next edition of
Common Lisp:
STRING-CHAR-CODE-LIMIT
The upper bound of character codes in string characters.
(STRING-CHAR-P X) is equivalent to
(AND (<= 0 (CHAR-CODE X))
(< (CHAR-CODE X) STRING-CHAR-CODE-LIMIT))
READTABLE-CHAR-CODE-LIMIT
The upper bound of character codes for characters which may be
readtable indices, i.e. legal first arguments to
SET-SYNTAX-FROM-CHAR, SET-MACRO-CHARACTER, etc.
In many implementations CHAR-CODE-LIMIT is the same as
STRING-CHAR-CODE-LIMIT and READTABLE-CHAR-CODE-LIMIT, but not in all
implementations, for example Symbolics Common Lisp.
∂01-Sep-85 0743 FAHLMAN@CMU-CS-C.ARPA New constants needed
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Sep 85 07:43:21 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 1 Sep 85 10:43:45-EDT
Date: Sun, 1 Sep 1985 10:43 EDT
Message-ID: <FAHLMAN.12139787368.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: edsel!eb@λNavajo (Eric Benson)λ
Cc: Common-Lisp@SU-AI.ARPA
Subject: New constants needed
In-reply-to: Msg of 31 Aug 1985 17:45-EDT from edsel!eb at Navajo (Eric Benson)
I have no particular objection to your proposed new constants, but I
don't see the reason for String-Char-Code-Limit, as long as each
implementation is required to provide a correct implementation of
String-Char-P. Requiring such a limit would implicitly require that the
string chars occupy a continuous range starting at 0 and with no holes.
I don't think we require that now, and it might be awkward for some odd
encodings -- I'm not sure what EBCDIC does. If it were up to me, we'd
just define the language in terms of ASCII and be done with it, but if
we are going to straddle the fence on this (as Guy has done so
carefully), we must be careful not to fall off.
I suppose that if we were to define these limits as bounds on the set of
legal string or readtable characters, without saying that characters
within these bounds are necessarily legal, then we can at least use them
to see how large certain tables and fields have to be. CHAR-CODE-LIMIT
already gives us a loose bound of this sort, but perhaps these other
numbers would give a somewhat tighter bound for some implementations.
-- Scott
∂01-Sep-85 0942 greek@DEC-HUDSON Letting LET bind the same variable more than once.
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 1 Sep 85 09:42:01 PDT
Date: Sun, 01 Sep 85 12:43:31 EDT
From: greek@DEC-HUDSON
Subject: Letting LET bind the same variable more than once.
To: common-lisp@su-ai
I would have thought that was an error. It's OK for LET*, but just
seems like a mess for LET.
- Paul
∂01-Sep-85 0948 greek@DEC-HUDSON STRING-CHAR-CODE-LIMIT
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 1 Sep 85 09:48:08 PDT
Date: Sun, 01 Sep 85 12:49:37 EDT
From: greek@DEC-HUDSON
Subject: STRING-CHAR-CODE-LIMIT
To: common-lisp@su-ai
The definition given for STRING-CHAR-CODE-LIMIT is too simplistic.
In VAX LISP for example, a character can't have bits or font if it
is to be stored into a simple-string.
As Scott says, STRING-CHAR-P exists exactly so that you can find out
if a character is a string-char. You might want to build a table with
an entry for every string-char; then STRING-CHAR-CODE-LIMIT might
be useful. However, you can figure out how big to make the table
using CODE-CHAR.
I guess it would be wrong to assume that STRING-CHAR-CODE-LIMIT =
CHAR-CODE-LIMIT. But I bet that equality holds for every implementation.
- Paul
∂01-Sep-85 1606 LOOSEMORE@UTAH-20.ARPA compiling multiple files
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 1 Sep 85 16:06:43 PDT
Date: Sun 1 Sep 85 17:08:44-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: compiling multiple files
To: common-lisp@SU-AI.ARPA
Message-ID: <12139879306.28.LOOSEMORE@UTAH-20.ARPA>
I cannot find any mention in the CLM of how one might compile several
source files into a single binary file. Most dialects of FORTRAN, C,
etc. have some sort of "include" construct to allow indirection. In PSL,
the DSKIN function serves this purpose; if the compiler sees a DSKIN as a
top level form, it will compile the forms within that file rather than
compiling a call to DSKIN. Typically, this is used to modularize
nonportable code into separate files for each system instead of lumping
everything together into a single file. It's much less awkward than #+ and
#- when dealing with a half-dozen different implementations and many pages
of implementation-specific code for each case.
I realize it is not too difficult to write a macro to do this in CL, but it
seems like this feature would be useful enough to be standardized. Do any
CL implementations already provide such a feature? Or have I missed
something in the manual?
-Sandra
-------
∂01-Sep-85 1944 Moon@SCRC-STONY-BROOK.ARPA STRING-CHAR-CODE-LIMIT
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Sep 85 19:44:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 304826; Sun 1-Sep-85 22:36:36-EDT
Date: Sun, 1 Sep 85 22:37 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: STRING-CHAR-CODE-LIMIT
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 1 Sep 85 12:49-EDT from greek@DEC-HUDSON
Message-ID: <850901223739.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 01 Sep 85 12:49:37 EDT
From: greek@DEC-HUDSON
I guess it would be wrong to assume that STRING-CHAR-CODE-LIMIT =
CHAR-CODE-LIMIT. But I bet that equality holds for every implementation.
Pay up. :-)
∂02-Sep-85 1519 Masinter.pa@Xerox.ARPA Re: lexical madness
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 2 Sep 85 15:18:55 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 02 SEP 85 15:19:36 PDT
Date: 2 Sep 85 15:27 PDT
From: Masinter.pa@Xerox.ARPA
Subject: Re: lexical madness
In-reply-to: Richard Mlynarik <MLY@MIT-MC.ARPA>'s message of Sat, 31 Aug
85 09:16:45 EDT
To: MLY@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA
Message-ID: <850902-151936-2212@Xerox>
there's no reason for the order to be "unpredictable". It would be more
reasonable to say "all all assigments are done in left-to-right order".
A smart compiler can then possibly detect that none of the variables are
duplicated and that there are no interrupts and thus it doesn't matter
what order they're done in.
Similarly, LET should be defined so that the last binding of a variable
is the one that applies.
Would removing this ambiguity in the language seriously affect any
current implementation?
∂02-Sep-85 1745 Masinter.pa@Xerox.ARPA Re: Side effecting constants inside functions
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 2 Sep 85 17:45:39 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 02 SEP 85 17:45:37 PDT
Date: 2 Sep 85 17:53 PDT
From: Masinter.pa@Xerox.ARPA
Subject: Re: Side effecting constants inside functions
In-reply-to: Charles Hornig <Hornig@SCRC-STONY-BROOK.ARPA>'s message of
Mon, 26 Aug 85 10:36 EDT
To: TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
Message-ID: <850902-174537-2252@Xerox>
What's wrong with this style? Normally, there's an invariant that
running a piece of code doesn't change its semantics, or how it prints
out. The example you gave violates that invariant, and thus seems
clearly to be "bad style". (A lot of things attributed to "style"
actually have good reasons behind them, if you think about it.) (Your
example doesn't act like a lexical closure because its not reentrant.)
Here's a more reasonable, although not compelling, example.
(defmacro compute-once (form)
`(let ((value '(,nil . ,nil)))
(cond ((car value) (cdr value))
(t (setf (car value) t)
(setf (cdr value) ,form))))
(compute-once <compute-stuff>) executes <compute-stuff> once, the first
time it is run.
Well, its a more reasonable example... I have to admit that I thought it
was pretty awful when I first saw it, but then, that's what I thought of
#. too.
∂02-Sep-85 1808 Masinter.pa@Xerox.ARPA constructor function vs constructor macro
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 2 Sep 85 18:08:45 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 02 SEP 85 18:09:26 PDT
Date: 2 Sep 85 18:17 PDT
From: Masinter.pa@Xerox.ARPA
Subject: constructor function vs constructor macro
To: common-lisp@su-ai.ARPA
Message-ID: <850902-180926-2266@Xerox>
On p. 308, it says that defstruct defines a constructor function named
make-name, and talks about the automatically defined
constructor-function. However, on page 357, it says that #S calls the
constructor <macro>. Am I right in assuming that p 357 is wrong, and the
constructor is a function rather than a macro?
∂02-Sep-85 1829 FAHLMAN@CMU-CS-C.ARPA lexical madness
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Sep 85 18:29:05 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 2 Sep 85 21:29:41-EDT
Date: Mon, 2 Sep 1985 21:29 EDT
Message-ID: <FAHLMAN.12140167103.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Masinter.pa@XEROX.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: lexical madness
In-reply-to: Msg of 2 Sep 1985 18:27-EDT from Masinter.pa at Xerox.ARPA
Most implementations of PSETQ that I've seen eval the values onto the
stack and then pop and bind in reverse order. LET is sometimes handled
in the same way. Sure, we could remove the ambiguity by requiring every
compiler to be rewritten so that it looks for twice-bound variables in a
single parallel-binding form. But it seems to me that this is too much
extra work in order to remove the ambiguity in a profoundly worthless
case. I think we should just tell the user that if he really cares
which value X gets bound to, he shouldn't bind it twice in the same LET
or PSETQ.
-- Scott
∂02-Sep-85 1855 FAHLMAN@CMU-CS-C.ARPA constructor function vs constructor macro
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Sep 85 18:55:04 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 2 Sep 85 21:55:38-EDT
Date: Mon, 2 Sep 1985 21:55 EDT
Message-ID: <FAHLMAN.12140171825.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Masinter.pa@XEROX.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: constructor function vs constructor macro
In-reply-to: Msg of 2 Sep 1985 21:17-EDT from Masinter.pa at Xerox.ARPA
Yes, I think that section 19.3 makes very clear that the constructor
created by a defstruct is a function. There's certainly nothing about
the syntax described there that suggests that the constructor should be
a macro. Looks to me like the use of the word "macro" on page 357 is
wrong.
-- Scott
∂02-Sep-85 2203 EVAN@SU-CSLI.ARPA Re: Side effecting constants inside functions
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 2 Sep 85 22:02:29 PDT
Date: Mon 2 Sep 85 22:01:34-PDT
From: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Subject: Re: Side effecting constants inside functions
To: Masinter.pa@XEROX.ARPA
cc: TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA, evan@SU-CSLI.ARPA
In-Reply-To: Message from "Masinter.pa@Xerox.ARPA" of Mon 2 Sep 85 17:53:00-PDT
>(defmacro compute-once (form)
> `(let ((value '(,nil . ,nil)))
> (cond ((car value) (cdr value))
> (t (setf (car value) t)
> (setf (cdr value) ,form))))
But wouldn't it be more reasonable to do something more like:
(defmacro compute-once (form)
(let ((var (gensym)))
`(if (boundp ',var)
,var
(setf ,var ,form))))
This lacks the self-modifying-ness of the original example.
-------
∂03-Sep-85 0240 EVAN@SU-CSLI.ARPA Re: Side effecting constants inside functions
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 02:38:22 PDT
Date: Tue 3 Sep 85 02:37:29-PDT
From: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Subject: Re: Side effecting constants inside functions
To: Masinter.pa@XEROX.ARPA, TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA,
evan@SU-CSLI.ARPA
In-Reply-To: Message from "Evan Kirshenbaum <evan@SU-CSLI.ARPA>" of Mon 2 Sep 85 22:01:35-PDT
Actually, my earlier suggestion compiles inefficiently since it uses
a special variable in a way a compiler might not be able to catch and
simplify. A slightly better solution (more patterned after the original
suggestion) would be:
(defmacro compute-once (form)
(let ((cell (cons nil nil)))
`(if (car ',cell) (cdr ',cell)
(setf (car ',cell) ,form))))
The main difference between this and the original is that the let is done
at expansion time rather than at execution time. This code does modify
itself (although I had to try it out to make sure that it actually worked
the way I thought it would), but it doesn't run into the problem with
read-only areas that as inherent in the other one.
-------
∂03-Sep-85 0623 greek@DEC-HUDSON STRING-CHAR-CODE-LIMIT = CHAR-CODE-LIMIT
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 06:23:27 PDT
Date: Tue, 03 Sep 85 09:24:57 EDT
From: greek@DEC-HUDSON
Subject: STRING-CHAR-CODE-LIMIT = CHAR-CODE-LIMIT
To: common-lisp@su-ai
Yes, now that I think about the rich repertoire of keys on the 3600's
keyboard, that was clearly a stupid bet I made. I owe Mr. Moon a beer.
- Paul
∂03-Sep-85 0720 smh@mit-ems.ARPA Re: Side effecting constants inside functions
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 07:19:49 PDT
Received: by mit-ems.ARPA (4.12/4.8) id AA20078; Tue, 3 Sep 85 10:19:31 edt
Date: Tue, 3 Sep 85 10:19:31 edt
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8509031419.AA20078@mit-ems.ARPA>
To: Masinter.pa@XEROX.ARPA, TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA,
evan@SU-CSLI.ARPA
Subject: Re: Side effecting constants inside functions
> From: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
> Subject: Re: Side effecting constants inside functions
>
> ...
> (defmacro compute-once (form)
> (let ((cell (cons nil nil)))
> `(if (car ',cell) (cdr ',cell)
> (setf (car ',cell) ,form))))
> ...
All these proposed mechanisms work in compiled code, but CLtL
intentionally [?] provides no guarantee that a macro will be expanded
only the first time an interpreted function is evaluated. Questionable
macro hacks like these are a wonderful tool to retain a few
unpredictable differences between compiler and interpreter semantics in
the language ;-).
The original issue was whether modification of code or internal
constants in code ought be defined in the language. I plead all code
modification should be `an error', but with no guarantee that the error
will be signalled. (In particular, the practice might happen to work
in some implementations.) This is exactly the situation now. The only
change would be to the manual. Below is an attempt at a clean formal
statement:
=====
It is an error to attempt subsequently to modify the closure created
when the @I(function) special form is passed a lambda expression. (It
may, of course, be discarded.) For these purposes, defun, defmacro,
and friends such as defstruct may all be considered to create functions
by evaluating a @I(function) special form.
Note: The function created by defmacro, of course, is not the macro
itself, but the unnamed lambda stored in the macro-function cell of the
named symbol.
=====
I anticipate argument that this restriction makes impossible all the
neat code modification hacks for which lisp is famous. So be it.
Hacking the insides of a lambda has never worked for compiled code, and
(p.143):
an implementation of Common Lisp has great latitude in
deciding exactly when to expand macro calls inside a program.
... (An implementation might even choose always to compile
functions defined by @B(defun), even when operating in an
"interpretive" mode!)
It is but a small additional step to permit "(function (lambda ... ))"
also to invoke the compiler, and on this CLtL is silent. (I admit the
performance issues might be horrendous in some cases.) Remember,
messing with the innards of a lambda, for example, changing the
identity of lexically referenced variables, completely invalidates any
lexical analysis performed by @I(function). Read p.89 for details. If
one feels it is absolutely necessary to modify code, the correct way to
do it is by passing a form to an explicit call to eval.
A final side issue: Perhaps CLtL should provide a plausible *sketch*
for the defun macro. This would make clearer to the neophyte the
connection between @I(defun) and @I(function). Something simple,
ignoring any messy complications, like:
(defmacro defun (name lambda-list . body)
`(setf (symbol-function ,name)
(function (lambda ,lambda-list ,@body))))
∂03-Sep-85 1024 DLW@SCRC-VALLECITO.ARPA Re: Side effecting constants inside functions
Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 10:23:52 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 32398; Tue 3-Sep-85 13:23:46-EDT
Date: Tue, 3 Sep 85 13:22 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Re: Side effecting constants inside functions
To: evan@SU-CSLI.ARPA, Masinter.pa@XEROX.ARPA
cc: TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 3 Sep 85 01:01-EDT from Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Message-ID: <850903132259.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Date: Mon 2 Sep 85 22:01:34-PDT
From: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
(defmacro compute-once (form)
(let ((var (gensym)))
`(if (boundp ',var)
,var
(setf ,var ,form))))
This lacks the self-modifying-ness of the original example.
And it doesn't work, if you run it interpreted and the interpreter
handles macros in the straightforward way (no automatic memoization,
etc). A new symbol is created each time by the call to gensym.
I believe that the claim in CLtL that the interpreter and the compiler
have precisely the same semantics "so far as possible" must be read with
the understanding that the semantics can differ in the face of macros
whose expansion causes side-effects.
∂03-Sep-85 1039 DLW@SCRC-QUABBIN.ARPA Re: Side effecting constants inside functions
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 10:34:06 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 197331; Tue 3-Sep-85 13:33:07-EDT
Date: Tue, 3 Sep 85 13:33 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Re: Side effecting constants inside functions
To: evan@SU-CSLI.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 3 Sep 85 05:37-EDT from Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Message-ID: <850903133318.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Date: Tue 3 Sep 85 02:37:29-PDT
From: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
(defmacro compute-once (form)
(let ((cell (cons nil nil)))
`(if (car ',cell) (cdr ',cell)
(setf (car ',cell) ,form))))
This has a bug too: if the form returns NIL, it will be computed more
than once.
However, the more interesting point is that it returns a form that has
internal sharing of list structure. It seems quite possible to me that
some Common Lisp implementation out there might not handle this
properly. For example, if a function using this compute-once were
written in a file, and the file were compiled with compile-file, and the
resulting bin file were loaded, the resulting compiled function might
end up having three different copies of the cell.
Another way to look at it is that the expansion of a function that
uses compute-once will be a piece of list structure that has no
readable printed representation. That is, the macro lets you build
programs that are impossible to type in directly.
In my opinion, a Common Lisp implementation should not be required to
deal with cases such as this, just as it is not required to deal with
iteration implemented out of circular CONDs.
∂03-Sep-85 1207 EVAN@SU-CSLI.ARPA Re: Side effecting constants inside functions
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 12:06:52 PDT
Date: Tue 3 Sep 85 12:05:09-PDT
From: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Subject: Re: Side effecting constants inside functions
To: DLW@SCRC-QUABBIN.ARPA
cc: Masinter.pa@XEROX.ARPA, TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA,
evan@SU-CSLI.ARPA
In-Reply-To: Message from "Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>" of Tue 3 Sep 85 10:24:32-PDT
Well, it ran on my interpreter (Hedrick's TOPS-20), and that's roughly
the form I have used in the past. Out of curiousity, is there any way
to define a form which caches values (computes them once) that is not
self-modifying? I have more than a casual interest, as this is a problem
we are facing in a language I'm working on.
evan
-------
∂03-Sep-85 1220 EVAN@SU-CSLI.ARPA Re: Side effecting constants inside functions
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 12:19:01 PDT
Date: Tue 3 Sep 85 12:17:46-PDT
From: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Subject: Re: Side effecting constants inside functions
To: DLW@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, evan@SU-CSLI.ARPA
In-Reply-To: Message from "Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>" of Tue 3 Sep 85 10:36:01-PDT
Whoops! I didn't look at the function I sent. I inserted it from a file,
and of course it was the wrong file (a first attempt). The final version
is of course:
(defmacro compute-once (form)
(let ((cell (cons nil nil)))
`(if (car ',cell) (cdr ',cell)
(progn
(setf (car ',cell) t)
(setf (cdr ',cell) ,form)))))
Which uses the car as a valuep flag and the cdr as a value field.
As to typing it in directly, could you do something like (this hasn't been
tested):
(if (car '#1:(nil)) (cdr '#1#)
(progn (setf (car '#1#) t) (setf (cdr '#1#) <form>)))
This notation has come in handy more than once. Unfortunately, unless
there is another way to do things like caching, Common Lisp should have
some concrete definition of what we can and can't expect the semantics of
code which is self modifying or contains shared structure to be.
evan
-------
∂03-Sep-85 1310 REM%IMSSS.#Pup@SU-SCORE.ARPA shared structure, other restrictions on program=data
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 13:10:07 PDT
Received: from IMSSS by Score with Pup; Tue 3 Sep 85 13:08:42-PDT
Date: 3 Sep 1985 1306-PDT
From: Rem@IMSSS
Subject: shared structure, other restrictions on program=data
To: COMMON-LISP%SU-AI@SCORE
It is well known that not all valid LISP data objects are executable forms.
But which restrictions are enforced by CL and which aren't doesn't seem
clear/obvious and should be spelled out in the manual.
Dotted lists are illegal at the toplevel of any form (and recursively
at the toplevel of any sub-form that gets EVALuated), except in the
case of macro forms before expansion. That part is obvious to nearly all.
Car of form must be a lambda expression or defined function or macro,
number and type of arguments must be correct, etc., etc., all obvious.
No shared structure may be present, even in quoted data, in a form.
This is surprizing, but has come up in this current discussion.
This applies both to shared structure typed in via the #: mechanism,
and to expansions of macros that generate multiple references to
some structure. This all should be documented clearly.
No undeclared free variables may be referenced. This causes a difference
between interpreted and compiled behaviour in other LISPs, but causes
both interpretor and compiler to fail the same in CL.
Any other restrictions I missed?
-------
∂03-Sep-85 1619 DLW@SCRC-QUABBIN.ARPA constructor function vs constructor macro
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 16:18:51 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 197360; Tue 3-Sep-85 14:15:31-EDT
Date: Tue, 3 Sep 85 14:15 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: constructor function vs constructor macro
To: Fahlman@CMU-CS-C.ARPA, Masinter.pa@XEROX.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12140171825.BABYL@CMU-CS-C.ARPA>
Message-ID: <850903141553.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Date: Mon, 2 Sep 1985 21:55 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Looks to me like the use of the word "macro" on page 357 is wrong.
Agreed. This is probably a hangover from Zetalisp, in which the
constructors really are macros. This micro-mistake has been around at
least since the Colander Edition.
∂03-Sep-85 1619 DLW@SCRC-QUABBIN.ARPA Re: lexical madness
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 16:19:15 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 197368; Tue 3-Sep-85 14:29:06-EDT
Date: Tue, 3 Sep 85 14:29 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Re: lexical madness
To: Masinter.pa@XEROX.ARPA, MLY@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850902-151936-2212@Xerox>
Message-ID: <850903142930.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Date: 2 Sep 85 15:27 PDT
From: Masinter.pa@Xerox.ARPA
Would removing this ambiguity in the language seriously affect any
current implementation?
Our implementation considers a LET that names the same variable twice to
be in error. The interpreter does not check for the error, but the
compiler does and signals an error. When I wrote that part of the
compiler in 1981, Common Lisp was still in its early stages of life, but
I thought it was apparent that such a case is an error. I still think
that it ought to be considered an error, since to define it to be legal,
with any of the possible meanings that suggest themselves, would only
introduce a construct that would be confusing to someone reading the
program, and which has no benefits of its own.
∂03-Sep-85 1627 wilensky@ucblarch inconsistency in the definitions of round-off functions
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 16:26:51 PDT
Received: from ucblarch.ARPA by UCB-VAX.ARPA (4.24/5.3)
id AA07954; Tue, 3 Sep 85 16:24:05 pdt
Date: Tue, 3 Sep 85 16:25:13 pdt
From: wilensky@ucblarch (Robert Wilensky)
Message-Id: <8509032325.6681@ucblarch.ARPA>
Received: by ucblarch.ARPA (2.0/3.5)
id AA06681; Tue, 3 Sep 85 16:25:13 pdt
To: common-lisp@su-ai
Subject: inconsistency in the definitions of round-off functions
Cc: hilfingr%ernie@Berkeley, fateman%dali@Berkeley, wilensky%dali@Berkeley,
jkf%mike@Berkeley
The definition of the functions ``floor'', etc. is inconsistent. In one
paragraph (p. 216) it is stated that ``(floor 5 2) is equivalent to (floor
(/ 5 2))''. However, according to the very next paragraph, this is not true
of the second value returned. This is because, ``If any of these functions
is given the two arguments x and y and produces results q and r, then q . y
+ r = x''. Thus, ``(floor 5 2)'' returns 2 and 1, while ``(floor (/ 5 2))''
returns 2 and 1/2. This is fact appears to be true of VAXLISP.
∂03-Sep-85 1849 SCHUMACHER%hp-hulk.csnet@csnet-relay.arpa Re: compiling multiple files
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 18:49:22 PDT
Received: from hplabs by csnet-relay.csnet id ar25737; 3 Sep 85 21:34 EDT
Received: by HP-VENUS id AA17278; Tue, 3 Sep 85 16:57:06 pdt
Message-Id: <8509032357.AA17278@HP-VENUS>
Date: Tue 3 Sep 85 16:57:21-PDT
From: SCHUMACHER%hplabs.csnet@csnet-relay.arpa
Subject: Re: compiling multiple files
To: LOOSEMORE
Cc: common-lisp@su-ai.ARPA
In-Reply-To: Message from "SANDRA <LOOSEMORE@UTAH-20@HP-VENUS>" of Mon 2 Sep 85 04:33:30-PDT
Source-Info: From (or Sender) name not authenticated.
What you need can be done using the require function (sec 11.8 modules in CLtL)
assuming that the appropriate provide calls have been made, or you can
simply use (eval-when (eval compile) (load ...)) .
Lee Schumacher
-------
∂03-Sep-85 2111 edsel!eb@su-navajo.arpa Modifying constants in programs
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 21:11:22 PDT
Received: by su-navajo.arpa with TCP; Tue, 3 Sep 85 21:10:23 pdt
Received: by edsel.uucp (2.0/SMI-2.0)
id AA16018; Tue, 3 Sep 85 20:07:30 pdt
Date: Tue, 3 Sep 85 20:07:30 pdt
From: edsel!eb@su-navajo.arpa (Eric Benson)
Message-Id: <8509040307.AA16018@edsel.uucp>
To: navajo!Common-Lisp@SAIL
Subject: Modifying constants in programs
Here is a paragraph from CLtL which has some bearing on the discussion
of modifying constants in code:
''An additional problem with EQ is that the implementation is permitted to
"collapse" constants (or portions thereof) appearing in code to be
compiled if they are EQUAL. An object is considered to be a constant in
code to be compiled if it is a self-evaluating form or is contained in a
QUOTE form. This is why (EQ "Foo" "Foo") might be true or false; in
interpreted code it would normally be false, because reading in the form
(EQ "Foo" "Foo") would construct distinct strings for the two arguments
to EQ, but the compiler might choose to use the same identical string or
two distinct copies as the two arguments in the call to EQ. Similarly,
(EQ '(A . B) '(A . B)) might be true or false, depending on whether the
constant conses appearing in the QUOTE forms were collapsed by the
compiler. However, (EQ (CONS 'A 'B) (CONS 'A 'B)) is always false,
because every distinct call to the CONS function necessarily produces a
new and distinct cons.''
This implies that it is illegal to modify a constant in compiled code,
since the compiler is licensed to share all or part of that constant
with other compiled code.
For the particular example of COMPUTE-ONCE, it is not necessary to use a
special variable to hold the computed value. A lexical variable will
suffice. The scope of the lexical variable must include the entire
function in which it is referenced. This is similar to an OWN variable
in Algol 60.
∂04-Sep-85 0301 RWK@SCRC-STONY-BROOK.ARPA Re: compiling multiple files
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 03:01:04 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 305986; Wed 4-Sep-85 05:59:18-EDT
Date: Wed, 4 Sep 85 06:00 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Re: compiling multiple files
To: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA
cc: LOOSEMORE%hplabs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8509032357.AA17278@HP-VENUS>
Message-ID: <850904060013.0.RWK@CROW.SCRC.Symbolics.COM>
Date: Tue 3 Sep 85 16:57:21-PDT
From: SCHUMACHER%hplabs.csnet@csnet-relay.arpa
What you need can be done using the require function (sec 11.8 modules in CLtL)
assuming that the appropriate provide calls have been made, or you can
simply use (eval-when (eval compile) (load ...)) .
Lee Schumacher
-------
This isn't the same thing at all, especially this last
suggestion. Loading a file into the compilation
environment is not the same as compiling it into the file!
Nor is putting a REQUIRE into a file the same as compiling
the required software into a resulting file, which is what
was request.
I believe this describes the desired behaviour:
(defmacro insert-file-and-compile (file)
(with-open-file (stream file)
(do* ((eof (cons 'eof nil))
(form (read stream nil eof) (read stream nil eof))
(forms))
((eq form eof)
`(progn ,@(nreverse forms)))
(push form forms))))
∂04-Sep-85 0604 REM%IMSSS.#Pup@SU-SCORE.ARPA LISP has both pure and reference data types
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 06:04:49 PDT
Received: from IMSSS by Score with Pup; Wed 4 Sep 85 06:03:43-PDT
Date: 4 Sep 1985 0601-PDT
From: Rem@IMSSS
Subject: LISP has both pure and reference data types
To: COMMON-LISP%SU-AI@SCORE
Tonite while thinking about my work interfacing PSL to Fortran, and recent
discussions about how in CL you aren't supposed to modify any structure
that was quoted in sourcecode, it occurred to me that LISP in general has
two distinct classes of data, which point hasn't been raised in any manual
I've read: (1) pure data, readonly, you are assured nobody will change it
out from under you, but to compute a new value you must allocate new memory;
(2) reference data, readwrite, designed to efficiently share side-effects
and/or to efficiently compute new values in place without having to allocate
a new place to put the newly-computed value. You can't mix the two. If you
try to modify a datum that somebody else expects to be pure, all hell breaks
loose, constants change out from under programs or you get a memory exception
from trying to modify a readonly page. But if you go to the bother of making
reference data but then don't bother to ever modify it in place, rather always
copy the whole thing to new memory every time you change something, your
program runs really slow.
Examples of pure data are: integers and reals (and complexes and rationals
in CL), strings that are given by syntax "...", and any other expression
that is given in source code explicitly or generated by macro expansion.
Examples of reference data are: all arrays constructed at runtime (which
generally means *all* arrays since most LISPs don't have a syntax for giving
arrays explicitly in source), any other non-atomic object that is created
at runtime, value cells, property-list cells, funtion cells.
Perhaps LISP (read CL and PSL) should make the distinction explicit, perhaps
even having parallel datatypes for those which are supposed to be readonly
(write once when allocating, thence readonly until GC'd) and those which are
supposed to be modifyable. For example, you could compute an integer cell
which had an initial value but that value could be changed out from under
the functions that referenced it, so that the side effects of changing that
integer could be shared more efficiently than if you shared the name of a
global or lexical variable whose value cell was modified to point to different
integers, and you could safely pass that integer cell to FORTRAN or other
software that wanted to modify the value in place; but you could also keep
around oldstyle integers that weren't supposed to be changed, and any
FORTRAN interface or other software could automatically know to make a copy
of the integer into a reference-integer cell before proceeding with the
code that modified it, leaving the oldstyle integer unmunged. Having
explicit data types for pure-integer versus modifyable-integer would be
cleaner than trapping memory exceptions on attempt to modify a readonly page,
and implementable on more systems.
Meanwhile, it should be documented that currently LISP doesn't have such
distinct data types in the language nor in most implementations, so it's
up to the user to manually keep track of which values are safe to change
and which aren't (and thus to be massively copied before passing them to
a routine which will modify in place for efficiency).
Also, perhaps we should have some new functions that do arithmetic in place,
to support efficient arithmetic in cases where shared type-declared lexical
variables aren't efficient enough or aren't general enough?
Thus in addition to Value <- (+ A B C ... Z) which can generate slightly
efficient code when all arguments are declared integer or real, we can
have (+InPlace Result A B C ... Z) which requires all arguments including
Result to be declared of the same type, likewise for the other primitive
arithmetic functions. +InPlace would not have to do a number-cons, even
if Result was a place deep inside some s-expression that was assumed
(user's responsibility currently) to already contain a modifyable number
of the correct type.
-------
∂04-Sep-85 0614 REM%IMSSS.#Pup@SU-SCORE.ARPA More on reference/pure data, declaration not really needed
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 06:14:49 PDT
Received: from IMSSS by Score with Pup; Wed 4 Sep 85 06:13:43-PDT
Date: 4 Sep 1985 0615-PDT
From: Rem@IMSSS
Subject: More on reference/pure data, declaration not really needed
To: common-lisp%SU-AI@SCORE
After sending that message I realized declarations aren't needed in the
case of (+InPlace Result A B C ... Z). The only true requirement is that
Result get initialized to a modifyable number of the desired type before
calling +InPlace. +InPlace would compute the result as normal, except
being careful not to do any number-consing, then would coerce the result
to the same type as Result previously had, and modify Result to contain
that result.
Note that when you use +InPlace you lose the ability to nest function
calls, thus the in-place-efficient version of (SETQ A (+ B (* C D)))
would be (PROGN (*InPlace A C D) (+InPlace A A B)) using A as a temporary,
although a smart compiler or interpretor ought to be able to recognize
(+InPlace A B (* C D)) and convert it into a totally-efficient calculation
so the user can retain the ability to nest * inside +(InPlace).
-------
∂04-Sep-85 0649 BSG@SCRC-STONY-BROOK.ARPA Re: Side effecting constants inside functions
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 06:49:39 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 306104; Wed 4-Sep-85 09:47:16-EDT
Date: Wed, 4 Sep 85 09:54 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Re: Side effecting constants inside functions
To: evan@SU-CSLI.ARPA, DLW@SCRC-QUABBIN.ARPA
cc: Masinter.pa@XEROX.ARPA, TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 3 Sep 85 15:05-EDT from Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Message-ID: <850904095440.6.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Tue 3 Sep 85 12:05:09-PDT
From: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Well, it ran on my interpreter (Hedrick's TOPS-20), and that's roughly
the form I have used in the past. Out of curiousity, is there any way
to define a form which caches values (computes them once) that is not
self-modifying? I have more than a casual interest, as this is a problem
we are facing in a language I'm working on.
evan
-------
I have mixed feelings about the ritual legality of this:
(defun switch ()
(let ((y '#.(generate-cellx)))
(prog1 (car y) (rplaca y t))))
(defun generate-cellx () (cons nil nil))
∂04-Sep-85 0804 LOOSEMORE@UTAH-20.ARPA Re: compiling multiple files
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 08:04:34 PDT
Date: Wed 4 Sep 85 09:06:07-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: Re: compiling multiple files
To: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8509032357.AA17278@HP-VENUS>
Message-ID: <12140577882.31.LOOSEMORE@UTAH-20.ARPA>
I believe a distinction needs to be made here between "loading" a file and
having a file processed by the compiler. Using
(eval-when (eval compile) (load "foobar"))
would be appropriate when the file "foobar" contains definitions (macros,
etc.) that are required a compile time. However, this form alone, even if
seen in a compilation context, would *not* cause the contents of file "foobar"
to be compiled.
Again, what I'm looking for is a function/macro/special form that causes the
contents of a given file to be processed exactly as if the forms within the
file were replacing the call to this function/macro/special form. A possible
(though inefficient) implementation as a macro would look something like:
(defmacro include-file (pathname)
(let ((results nil)
(form nil))
(with-open-file (stream pathname :direction :input)
(loop
(setq form (read stream nil '*eof*))
(if (eq form '*eof*)
(return nil)
(push form results))))
`(progn ,@(nreverse results))))
-Sandra
-------
∂04-Sep-85 0834 FAHLMAN@CMU-CS-C.ARPA inconsistency in the definitions of round-off functions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 08:32:39 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 4 Sep 85 11:33:18-EDT
Date: Wed, 4 Sep 1985 11:33 EDT
Message-ID: <FAHLMAN.12140582815.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: inconsistency in the definitions of round-off functions
Responding to wilensky at ucblarch (Robert Wilensky).
I believe that the inconsistency you point out has already been
reported to this mailing list a couple of times and is on Steele's list
of things to fix up next time around. I believe that the resolution of
this is that the manual should say that (floor 5 2) is equivalent to
(floor (/ 5 2)) AS FAR AS THE FIRST VALUE IS CONCERNED, but that the
treatment of the second return value is different.
Yes, I agree that we desperately need to get the current errata
collected and to make them available to the community. This is one of
the tasks for which we need some sort of support organization. We're
working on this, but it is going very slowly.
-- Scott
∂04-Sep-85 0843 DCP@SCRC-YUKON.ARPA Re: compiling multiple files
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 08:42:55 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 149252; Wed 4-Sep-85 11:41:59-EDT
Date: Wed, 4 Sep 85 11:44 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Re: compiling multiple files
To: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>,
SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA
cc: LOOSEMORE%hplabs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <850904060013.0.RWK@CROW.SCRC.Symbolics.COM>
Message-ID: <850904114419.9.NFEP@NEPONSET.SCRC.Symbolics.COM>
Date: Wed, 4 Sep 85 06:00 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Date: Tue 3 Sep 85 16:57:21-PDT
From: SCHUMACHER%hplabs.csnet@csnet-relay.arpa
What you need can be done using the require function (sec 11.8 modules in CLtL)
assuming that the appropriate provide calls have been made, or you can
simply use (eval-when (eval compile) (load ...)) .
Lee Schumacher
-------
This isn't the same thing at all, especially this last
suggestion. Loading a file into the compilation
environment is not the same as compiling it into the file!
Nor is putting a REQUIRE into a file the same as compiling
the required software into a resulting file, which is what
was request.
I believe this describes the desired behaviour:
(defmacro insert-file-and-compile (file)
(with-open-file (stream file)
(do* ((eof (cons 'eof nil))
(form (read stream nil eof) (read stream nil eof))
(forms))
((eq form eof)
`(progn ,@(nreverse forms)))
(push form forms))))
Nit: This isn't quite right because it doesn't take into account the
possible effects of eval-when which might change the readtable or
something for processing the rest of the file.
Instead of kludges like this, it would be better to have a defined
interface to the compiler which compiles a list of files. Maybe
COMPILE-FILE can simply be extended to allow a list as its first
argument, INPUT-FILE.
∂04-Sep-85 1208 gls@THINK-AQUINAS.ARPA Errata for Common Lisp manual
Received: from THINK.COM by SU-AI.ARPA with TCP; 4 Sep 85 12:08:26 PDT
Received: from polycarp by GODOT.THINK.COM via CHAOS; Wed, 4 Sep 85 15:07:24 edt
Date: Wed, 4 Sep 85 15:08 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Errata for Common Lisp manual
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <850904150821.2.GLS@POLYCARP.THINK.COM>
At the end of this message is my current list of "trivial" errata for
the Common Lisp manual. These are changes for problems that I regard as
either (a) simple typographical errors, or (b) ambiguities or
inconsistencies whose resolution is "obvious" and "noncontroversial".
As an example of an error for which a correction is not included here:
page 202 blithely states that "Mathematically, (lcm) should return
infinity." Wrong. Mathematically, the result should be 1, if anything.
(That's my fault, the result of fuzzy thinking.) The "obvious" fix is
to define (lcm) to return 1. However, that would not be merely a
textual correction, but a substantive change to the language possibly
requiring action by implementors, and it is not appropriate for me to
make such changes unilaterally.
--Guy
----------------------------------------------------------------
Corrections to first printing of Common Lisp: The Language
10 First two paragraphs should have monospace comma and colon,
respectively, at the left margin.
18 3.1010299957f-1 should be 3.010299957f-1 (first "1" should be deleted).
43 Table 43-1 should include the names "signed-byte" and "unsigned-byte".
67 The comment in (defun discriminant ...) is wrong, because the code
works for complex coefficients. Change the line
The quadratic equation a*x↑2+b*x+c=0 has real, multiple
to be the two lines
If the coefficients a, b, and c are all real numbers, then
the quadratic equation a*x↑2+b*x+c=0 has real, multiple
69 Top line, last word but one, should be "replace", not "replaces".
99 In first line of second paragraph, delete the italicized word "newvalue".
145 Three lines from the bottom, the term "&environment" should
appear at the left in monospace.
147 Last line on this page should be deleted; it duplicates first line
on page 148.
157 In third line, "declaration-form" should be "decl-spec" (in italics).
200 At the end of the first paragraph "returns the result." add the sentence
"It is an error if any argument other than the first is zero."
After "With one argument, / reciprocates the result" add the sentence
"The argument must not be zero."
204 Halfway down, the last line of a paragraph "#C(0.5 1.73205)."
should say "#C(1.0 1.73205)."
216 Alter "The divisor may be any non-complex number." to read
"The divisor may be any non-zero non-complex number."
216 Change "For example, (floor 5 2) @EQ (floor (/ 5 2)) ..." to
"For example, (values (floor 5 2)) @EQ (values (floor (/ 5 2))) ...".
[Actually, it would be better to rewrite this whole section, but this
fix at least makes it accurate.]
216 Before last paragraph, insert this new paragraph:
Note that while (floor 5 2) and (floor (/ 5 2)) return the same first
value, they return different remainders as the second value:
(floor 5 2) => 2 1
(floor (/ 5 2)) => 2 1/2
This is why @f[values] was used above in the remark that
(values (floor 5 2)) @EQ (values (floor (/ 5 2))).
276 Halfway down, in the display line before "See pushnew.", the phrase
"(fn item)" should be "(funcall fn item)", with "funcall" in monospace
and "fn" and "item" in italics as before.
307 In the header line for "defstruct", "{slot-description}+" should
be "{slot-description}*" (star instead of plus).
309 First paragraph should end "see section 19.6)." not "see section 19.6.";
there is a missing parenthesis.
325 The name of the variable "-" does not appear in the header line.
347-348 The page layout is a bit confused here; some connection should
be made between the description of ";" and the example.
349 Before the first complete paragraph, there should be a heading
line consisting of a single monospace backquote (accent grave).
349 In the first example of the use of backquote, the character
just before " (print ,x)" is a "t". (It is badly printed in several
copies.)
357 All occurrences of "constructor macro" should read "constructor function".
373 Third line from bottom: "print-array" in monospace should
be "*print-array*".
454 In index entry for "defun", first page number should be 67, not 57.
458 In index entry for "macrolet", page numbers should be 113-114 instead
of 93-94.
465 "zerop" is missing from the index (it is defined on page 195).
458 First reference for "macrolet" should be 113-114, not 93-94.
459 Add index entry "newline 20, 21-22, 235, 243, 336, 347, 378, 383, 384,
397".
∂04-Sep-85 1252 BROOKS%MIT-OZ@MIT-MC.ARPA Re: Errata for Common Lisp manual
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 12:50:57 PDT
Date: Wed 4 Sep 85 15:49:53-EDT
From: "Rodney A. Brooks" <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: Errata for Common Lisp manual
To: gls@AQUINAS.THINK.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850904150821.2.GLS@POLYCARP.THINK.COM>
Message-ID: <12140629539.28.BROOKS@MIT-OZ>
Another typo:
On page 221, and in the table on page 222, logorc1 and logorc2 are
used, but in the definitions of these at the top of page 222 they
are called logiorc1 and logiorc2.
-------
∂04-Sep-85 1350 DLW@SCRC-STONY-BROOK.ARPA Re: Side effecting constants inside functions
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 13:49:54 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 306629; Wed 4-Sep-85 16:47:27-EDT
Date: Wed, 4 Sep 85 16:48 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Re: Side effecting constants inside functions
To: evan@SU-CSLI.ARPA
cc: Masinter.pa@XEROX.ARPA, TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 3 Sep 85 15:05-EDT from Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Message-ID: <850904164848.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Date: Tue 3 Sep 85 12:05:09-PDT
From: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Out of curiousity, is there any way
to define a form which caches values (computes them once) that is not
self-modifying?
If there's a cache, there must be side-effects on some data structure
somewhere. Exactly where that state should be depends on what
circumstance should provoke the actual computation. If the computation
should happen only once per Lisp world, you could put it in a global
variable (or several global variables, or a global variable with
a structured value that can hold several objects).
∂04-Sep-85 1535 EVAN@SU-CSLI.ARPA GLisp for Common Lisp
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 15:35:32 PDT
Date: Wed 4 Sep 85 15:35:50-PDT
From: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Subject: GLisp for Common Lisp
To: common-lisp@SU-AI.ARPA
Does anyone know if there is a compiler for Gordon Novak's GLisp
language which compiles to Common Lisp?
Evan Kirshenbaum
-------
∂05-Sep-85 0714 wagner@GSWD-VMS Erratum
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 5 Sep 85 07:10:08 PDT
Date: Thu, 05 Sep 85 09:09:41 CDT
From: wagner@GSWD-VMS
Subject: Erratum
To: common-lisp@su-ai.arpa
Cc: wagner
In CLtL, page 287, bottom line, :type should be :element-type.
Fran
∂05-Sep-85 1037 RAM@CMU-CS-C.ARPA Top-level forms and eval-when in the compiler
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Sep 85 10:36:30 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 5 Sep 85 13:36:45-EDT
Date: Thu, 5 Sep 1985 13:36 EDT
Message-ID: <RAM.12140867427.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Top-level forms and eval-when in the compiler
There are various forms (defconstant, defmacro, eval-when) which
can cause things to happen in the compiler environment when they are
encountered. When at top-level, the correct action seems clear, but
anyplace else things become more confusing. What should be done when
a random (eval-when (compile) ...) is encountered during the
compilation of some function? Does the compiler always do
compile-time evaluation even though the code might be unreachable?
I don't think that it is acceptable to say that these forms are
only meaningful at top-level. In a lexical lisp it is quite
useful to put a definition inside of a let. Often user-defined
definition forms contain eval-whens.
Rob
∂05-Sep-85 2141 Moon@SCRC-YUKON.ARPA close queries
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 5 Sep 85 21:41:17 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 149830; Fri 6-Sep-85 00:40:17-EDT
Date: Fri, 6 Sep 85 00:41 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: close queries
To: robbins@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 21 Aug 85 13:59-EDT from robbins@DEC-HUDSON
Message-ID: <850906004107.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 21 Aug 85 13:59:15 EDT
From: robbins@DEC-HUDSON
What is supposed to happen when an attempt is made to close a synonym stream?
The manual seems to indicate that it is the stream which is bound to the
synonym symbol that should be closed, but, I am not sure that this is the
most desirable behaviour. What about someone that desires to close the
synonym stream but not the stream bound to the synonym symbol?
I don't see why close should be treated differently from other stream operations.
I don't know what it would mean to "close the synonym stream but not the stream
bound to" -- what aspect of a synonym stream is there to be closed, other than
the stream it is bound to?
Is it an error to close *terminal-io*?
I'd think so. Probably it's a no-op in a lot of implementations, but I can
imagine implementations where it would disconnect your terminal.
∂06-Sep-85 1154 franz!jkf@Berkeley Re: close queries
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 6 Sep 85 11:54:33 PDT
Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/5.3)
id AA03424; Fri, 6 Sep 85 11:51:41 pdt
Received: by ucbkim.ARPA (5.5/5.3)
id AA19258; Fri, 6 Sep 85 11:55:18 PDT
Received: by franz.UUCP (2.0/SMI-2.0)
id AA20802; Fri, 6 Sep 85 11:49:44 pdt
Date: Fri, 6 Sep 85 11:49:44 pdt
From: franz!jkf@Berkeley (John Foderaro)
Message-Id: <8509061849.AA20802@franz.UUCP>
To: Moon@SCRC-STONY-BROOK.ARPA, robbins@DEC-HUDSON.ARPA
Subject: Re: close queries
Cc: common-lisp@SU-AI.ARPA
In-Reply-To: Your message of Fri, 6 Sep 85 00:41 EDT
From: David A. Moon <ucbkim!Moon@SCRC-STONY-BROOK.ARPA>
I don't see why close should be treated differently from other
stream operations.
I don't know what it would mean to "close the synonym stream but
not the stream
bound to" -- what aspect of a synonym stream is there to be
closed, other than the stream it is bound to?
I disagree. When a synonym stream is 'opened', it creates a conduit to
another stream. When it is closed, the only action should be
to close the conduit, preventing further reading and writing operations
through the synonym stream. This is completely safe. Closing down the
stream bound to the synonym stream can be unsafe and you are forced to
come up with rules like 'you can close *terminal-io*' which is something
processes wish to do on occasion in Unix.
One way to decide which is the correct thing to do when a close is done
is to consider examples of synoynm streams. The only example I know of
is that *standard-input*, *standard-output*, *error-output*, *trace-output*,
*query-io*, and *debug-io* are all synonym streams for *terminal-io*.
It doesn't make sense to me that if I close *debug-io*, *standard-input*
should be affected, thus I claim this example supports my view.
Are there any other examples of synonym streams?
-john foderaro
∂06-Sep-85 1708 FAHLMAN@C.CS.CMU.EDU close queries
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 Sep 85 17:08:42 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 6 Sep 85 20:10:04-EDT
Date: Fri, 6 Sep 1985 20:10 EDT
Message-ID: <FAHLMAN.12141201186.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: franz!jkf@λBerkeley (John Foderaro)λ
Cc: common-lisp@SU-AI.ARPA
Subject: close queries
In-reply-to: Msg of 6 Sep 1985 14:49-EDT from franz!jkf at Berkeley (John Foderaro)
I think we've got some misunderstandings going here. For what it's
worth, I think Foderaro is right.
I think this is more or less what Moon was saying too, but it was
possible to read his meassge a couple of different ways.
-- Scott
∂06-Sep-85 2212 Moon@SCRC-STONY-BROOK.ARPA Re: close queries
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 6 Sep 85 22:12:26 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 308582; Sat 7-Sep-85 01:10:11-EDT
Date: Sat, 7 Sep 85 01:12 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: close queries
To: John Foderaro <franz!jkf@UCB-VAX.ARPA>
cc: robbins@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8509061849.AA20802@franz.UUCP>
Message-ID: <850907011208.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 6 Sep 85 11:49:44 pdt
From: franz!jkf@Berkeley (John Foderaro)
From: David A. Moon <ucbkim!Moon@SCRC-STONY-BROOK.ARPA>
I don't see why close should be treated differently from other
stream operations.
I don't know what it would mean to "close the synonym stream but
not the stream
bound to" -- what aspect of a synonym stream is there to be
closed, other than the stream it is bound to?
I disagree. When a synonym stream is 'opened', it creates a conduit to
another stream.
Since the function OPEN doesn't return synonym streams, it's difficult to
say what "a synonym stream is 'opened'" means exactly. I'd say
"a synonym stream is made'", since we make them by calling MAKE-SYNONYM-STREAM.
When it is closed, the only action should be
to close the conduit, preventing further reading and writing operations
through the synonym stream. This is completely safe. Closing down the
stream bound to the synonym stream can be unsafe and you are forced to
come up with rules like 'you can close *terminal-io*' which is something
processes wish to do on occasion in Unix.
This doesn't address my comment: I don't see why close should be treated
differently from other stream operations.
One way to decide which is the correct thing to do when a close is done
is to consider examples of synoynm streams. The only example I know of
is that *standard-input*, *standard-output*, *error-output*, *trace-output*,
*query-io*, and *debug-io* are all synonym streams for *terminal-io*.
It doesn't make sense to me that if I close *debug-io*, *standard-input*
should be affected, thus I claim this example supports my view.
If one adopts your suggestion that closing a synonym stream means to disconnect
it from the stream it forwards to, and prevent further operations on the
synonym stream, then surely closing *debug-io* is just as bad as closing
*terminal-io*. How you gonna debug it if *debug-io* doesn't work?
Let's look at it a different way: you propose for synonym streams to treat
CLOSE differently from all other stream operations. Okay, they could do that.
What would be gained by introducing this extra complexity, other than an
extra page of thickness of the manual?
∂07-Sep-85 1043 greek@DEC-HUDSON Closing Synonum Streams.
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 7 Sep 85 10:43:23 PDT
Date: Sat, 07 Sep 85 13:46:26 EDT
From: greek@DEC-HUDSON
Subject: Closing Synonum Streams.
To: common-lisp@su-ai
Moon is right -- it certainly would make CLOSE a special case if it only
closed the synonym stream and not the target stream. And we would have
to describe this "strange" behavior in CLtL. However, I still think
closing synonym streams should NOT close the target streams.
And synonym streams aren't the only special case. Broadcast, concatenated,
two-way, and echo streams should also not close the target streams.
Now a reasonable distinction emerges: indirect streams do not close their
target streams when they themselves are closed.
If these indirect streams do close their targets then you can never
close the stream created by DRIBBLE or you would surely end up closing
*TERMINAL-IO*. "You" here means the system itself.
Program A may create a stream that program B wants to use indirectly
(e.g., as a synonym stream or perhaps a target of a broadcast stream
or what have you). Certainly it is often the case that program B has
no right to close program A's stream just because B closes its own
indirect stream.
- Paul
∂07-Sep-85 1115 fateman%ucbdali@Berkeley comment and errata on synonyms, streams.
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 7 Sep 85 11:15:04 PDT
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/5.3)
id AA23511; Sat, 7 Sep 85 11:12:02 pdt
Received: by ucbdali.ARPA (5.5/4.48)
id AA12961; Sat, 7 Sep 85 11:13:04 PDT
Date: Sat, 7 Sep 85 11:13:04 PDT
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8509071813.AA12961@ucbdali.ARPA>
To: common-lisp@su-ai, greek@DEC-HUDSON
Subject: comment and errata on synonyms, streams.
The notion of synonym stream seems to me to be the inconsistency. Why
do we not have "make-synonym-symbol" by which we mean that
if we do (setq x (make-synonym-symbol 'y))
any operation performed on x is actually performed on y?
Then we could add an extra layer of indirection to ANYTHING. e.g.
(+ x x) would be like (+ y y). There are great uses for this. :-)
contribution to ERRATA:
In reading over the chapter on streams, I see on p331 of CLtL that
(with-input-from-string (s "Animal Crackers" :index j :start 6) (read s))
is alleged to return
crackers
This seems to me highly unlikely. It would be consistent if it returned
CRACKERS
An interesting puzzle is to figure out how to make it return the answer
Crackers
-- RJF
∂07-Sep-85 1337 franz!jkf@Berkeley longwinded reply to close queries
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 7 Sep 85 13:37:18 PDT
Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/5.3)
id AA25263; Sat, 7 Sep 85 13:34:29 pdt
Received: by ucbkim.ARPA (5.5/5.3)
id AA29871; Sat, 7 Sep 85 13:34:30 PDT
Received: by franz.uucp (5.5/3.14)
id AA25140; Sat, 7 Sep 85 12:55:26 PDT
Date: Sat, 7 Sep 85 12:55:26 PDT
From: franz!jkf@Berkeley (John Foderaro)
Message-Id: <8509071955.AA25140@franz.uucp>
To: Moon@SCRC-STONY-BROOK.ARPA
Subject: longwinded reply to close queries
Cc: common-lisp@SU-AI.ARPA, robbins@DEC-HUDSON.ARPA
In-Reply-To: Your message of Sat, 7 Sep 85 01:12 EDT
From: David A. Moon <ucbkim!Moon@SCRC-STONY-BROOK.ARPA>
Since the function OPEN doesn't return synonym streams, it's difficult to
say what "a synonym stream is 'opened'" means exactly. I'd say
"a synonym stream is made'", since we make them by calling
MAKE-SYNONYM-STREAM.
Sure, call it whatever you wish, I always think in terms of streams being
created by 'open' so I'll just use that term and you can mentally substitute
the appropriate function name.
This doesn't address my comment: I don't see why close should be treated
differently from other stream operations.
I can give a few reasons:
1) A stream has three classes of functions which operate on it:
creation/destruction
query (which file is connected, which byte position)
action (read/write)
A typical stream is atomic so all operations apply just to the stream.
A synonym stream (and the other make-xxx-stream types) are different.
As I see it, the creation/destruction function apply to the stream
itself, and the query and action functions apply to the bound stream.
Thus:
creation/destruction stream itself
-----
query bound stream
action
Of course what is needed are a set of query function that act on the
stream itself, providing such information as what symbol is the
synonym stream bound to, thus it really should be something like
this:
creation/destruction
query'
-----
query
action
In this model, making close act only on the synonym stream is
natural, and not an exception. You'll (probably) agree that
every other function already follows this model.
2) here is a puzzle:
(setq p (make-synonym-stream '*foo*))
Can I now safely (close p) if I using the semantics for close that
you believe are correct? How can I write a program in common lisp
to tell me if by doing a (close p) I won't shut off my keyboard and
display?
I can't think of a program and I would thus conclude that one should
never close a synonym stream.
3) The real question is of course what makes sense to do for real programs
doing real things.
Consider a simulation program which wants to watch and log ten different
types of events. It wants to create ten streams. At the start of
the simulation the user interactively decides for each even whether
the information should go in a file, or go to *standard-output* or
to *debug-io*. For the latter two cases, we create synonym streams.
In the middle of the simulation, after which time events of type X
should no long longer occur, we want to close the *x-event-stream*.
We can't just (close *x-event-stream*) or we may shut down
*terminal-io*. If we simply refuse to close a synonym stream
then we are forced to leave copies of this 'live' synonym stream
floating around and we can't detect when someone uses it again when
they really weren't supposed to.
--- end list--
From: David A. Moon <ucbkim!Moon@SCRC-STONY-BROOK.ARPA>
If one adopts your suggestion that closing a synonym stream means to disconnect
it from the stream it forwards to, and prevent further operations on the
synonym stream, then surely closing *debug-io* is just as bad as closing
*terminal-io*. How you gonna debug it if *debug-io* doesn't work?
I was just using *debug-io* as an example of a synonym stream, but as
long as you asked I can imagine a program that wants to use another stream
for *debug-io* first doing a close of *debug-io* before opening another
stream and storing it in *debug-io*.
Let's look at it a different way: you propose for synonym streams to treat
CLOSE differently from all other stream operations. Okay, they could do that.
What would be gained by introducing this extra complexity, other than an
extra page of thickness of the manual?
I would claim that without this extra complexity, synonym streams are too
dangerous to be used in most of the applications I would see for them.
-john foderaro
∂09-Sep-85 0910 DCP@SCRC-STONY-BROOK.ARPA go and return-from inside unwind-protect cleanup
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Sep 85 09:10:45 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 309229; Mon 9-Sep-85 09:39:13-EDT
Date: Mon, 9 Sep 85 09:43 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: go and return-from inside unwind-protect cleanup
To: Common-Lisp@SU-AI.ARPA
Message-ID: <850909094352.2.NFEP@NEPONSET.SCRC.Symbolics.COM>
Are the following legal?
(defun foo (go-p)
(prog nil
tag
(unwind-protect
(return (compute))
(if go-p (go tag)))))
(defun bar (return-p)
(prog nil
tag
(unwind-protect
(progn (compute)
(go tag))
(if return-p (return nil)))))
I say no, because the unwind-protect could be usurping the values of the
first form of unwind-protect (in the case of normal exit) or could be
usurping a THROW (in the abnormal exit).
There is no mention of this in CLtL (in the unwind-protect section, at
least). If it is legal, would somebody please tell me what FOO does.
∂09-Sep-85 0934 gls@THINK-AQUINAS.ARPA Closing Synonum Streams.
Received: from THINK.COM by SU-AI.ARPA with TCP; 9 Sep 85 09:33:42 PDT
Received: from ignatius by GODOT.THINK.COM via CHAOS; Mon, 9 Sep 85 12:32:33 edt
Date: Mon, 9 Sep 85 12:33 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Closing Synonum Streams.
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 7 Sep 85 13:46-EDT from greek at DEC-HUDSON
Message-Id: <850909123351.1.GLS@IGNATIUS.THINK.COM>
The subject header from GREEK was obviously a typo, but I cannot let it
pass. Surely we can design some clever language feature that deserves
the name "synonum".
--Quux
∂09-Sep-85 1001 gls@THINK-AQUINAS.ARPA go and return-from inside unwind-protect cleanup
Received: from THINK.COM by SU-AI.ARPA with TCP; 9 Sep 85 10:01:27 PDT
Received: from ignatius by GODOT.THINK.COM via CHAOS; Mon, 9 Sep 85 13:00:13 edt
Date: Mon, 9 Sep 85 13:01 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: go and return-from inside unwind-protect cleanup
To: DCP@SCRC-QUABBIN.ARPA, Common-Lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <850909094352.2.NFEP@NEPONSET.SCRC.Symbolics.COM>
Message-Id: <850909130121.2.GLS@IGNATIUS.THINK.COM>
Date: Mon, 9 Sep 85 09:43 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Are the following legal?
(defun foo (go-p)
(prog nil
tag
(unwind-protect
(return (compute))
(if go-p (go tag)))))
(defun bar (return-p)
(prog nil
tag
(unwind-protect
(progn (compute)
(go tag))
(if return-p (return nil)))))
I say no, because the unwind-protect could be usurping the values of the
first form of unwind-protect (in the case of normal exit) or could be
usurping a THROW (in the abnormal exit).
There is no mention of this in CLtL (in the unwind-protect section, at
least). If it is legal, would somebody please tell me what FOO does.
I regard both of these as completely legal. (FOO NIL) and (BAR T) call
COMPUTE exactly once. (FOO T) and (BAR NIL) call COMPUTE repeatedly.
These can be explained adequately in terms of continuations.
Informally, whenever some internal computational process that is
unwinding the stack (such as a RETURN, GO, or THROW) encounters an
UNWIND-PROTECT, it makes up a continuation that, when invoked, will
continue the stack-unwinding process and then perform whatever was to
occur after that (return a value, transfer to a tag, etc.). The cleanup
forms of the UNWIND-PROTECT are then executed with that continuation as
their continuation (that is, the action to be taken when they have all
been evaluated and control "flows off the end" of the implicit PROGN.
In the case of the protected form of a PROGN completing, the continuation is
"return a value from the UNWIND-PROTECT", and that is the continuation to
be performed after the cleanup forms.
GO, RETURN, and CATCH are operations that discard their normal continuations,
and perform some other control action instead.
In FOO, therefore, the use of RETURN begins a stack unwinding. Hitting
the UNWIND-PROTECT causes a "return the value of (COMPUTE) from the PROG"
continuation to be made up and used as the continuation for the expression
(IF GO-P (GO TAG)). If GO-P is NIL, the IF exits normally, the
return-continuation is used, and the PROG is exited. If GO-P is not NIL,
then the GO is executed, which discards its normal continuation, and so
it completely forgets that it was intending to return from the PROG.
Control is transfered to the tag. (A cleanup form is not protected by
its own UNWIND-PROTECT, and so no other unusual actions occur before
transfer to the tag.)
After completing this analysis, I tried out routines FOO and BAR both in
Symbolics 3600 Common Lisp and in DEC VAX LISP. In both implementations
both FOO and BAR behave exactly as I have described.
--Guy
∂10-Sep-85 1458 J.Dalton%edxa@ucl-cs.ARPA More errata
Received: from UCL-CS.ARPA by SU-AI.ARPA with TCP; 10 Sep 85 14:57:55 PDT
Received: from edxa.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a000917;
10 Sep 85 21:03 BST
From: DALTON FHL (on ERCC DEC-10) <J.Dalton%edxa@ucl-cs.arpa>
Date: Tuesday, 10-Sep-85 17:25:29-GMT
Message-ID: <132356-563-566@EDXA>
To: common-lisp <common-lisp%su-ai.arpa%cs.ucl.ac.uk@ucl-cs.arpa>,
J.Dalton%edxa@ucl-cs.arpa
Subject: More errata
--------
I hope the following textual errors have not been noted before:
461 The index entry "replacd" should be "rplacd".
189 In the line ";;; I just want a few thing from RELATIVITY,",
"thing" should be "things".
190-1 phlogiston:heat-flow is called with one argument on p. 190
but defined with three on p. 191.
191 In the function heat-flow, the symbol feeling-weak should
either be called as a function or declared special.
And one possible style-warning:
147 It's confusing (in the block of code near the bottom of the page)
to have cadr ... cadddr and then fifth. I'm not sure, though,
which way I'd want it instead.
-- Jeff Dalton, AIAI, University of Edinburgh
--------
∂10-Sep-85 2223 TIM@MIT-MC.ARPA Top-level forms and eval-when in the compiler [and macrolet too!]
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Sep 85 22:17:43 PDT
Date: Wed, 11 Sep 85 01:15:31 EDT
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject: Top-level forms and eval-when in the compiler [and macrolet too!]
To: RAM@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Thu 5 Sep 1985 13:36 EDT from Rob MacLachlan <RAM at CMU-CS-C.ARPA>
Message-ID: <[MIT-MC.ARPA].640743.850911.TIM>
Should a CL compiler generate interpreted or compiled definitions
for the the functions f and g in the following form?
(macrolet (...)
(defun f ...)
(defun g ...))
∂11-Sep-85 1133 JAR@MIT-MC.ARPA Top-level forms and eval-when in the compiler [and macrolet too!]
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 11 Sep 85 11:33:40 PDT
Date: Wed, 11 Sep 85 11:40:11 EDT
From: Jonathan A Rees <JAR@MIT-MC.ARPA>
Subject: Top-level forms and eval-when in the compiler [and macrolet too!]
To: TIM@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA, RAM@CMU-CS-C.ARPA
In-reply-to: Msg of Wed 11 Sep 85 01:15:31 EDT from Tim McNerney <TIM at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].641160.850911.JAR>
Date: Wed, 11 Sep 85 01:15:31 EDT
From: Tim McNerney <TIM at MIT-MC.ARPA>
Should a CL compiler generate interpreted or compiled definitions
for the the functions f and g in the following form?
(macrolet (...)
(defun f ...)
(defun g ...))
In my opinion, Lisp compilers should compile any LAMBDA-expressions,
explicit or implicit, which could possibly exist at and after load time.
So the answer is yes.
This subsumes the case of top-level
(setf (get 'foo 'bar) #'(lambda ...)),
The LAMBDA-expression doesn't get compiled by at least one aspiring
Common Lisp that I know of. One shouldn't have to do a DEFUN here just
in order to cause compilation to happen. That defeats the whole purpose
of anonymous functions.
Jonathan Rees
∂11-Sep-85 1144 FAHLMAN@C.CS.CMU.EDU Top-level forms and eval-when in the compiler [and macrolet too!]
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Sep 85 11:44:12 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 11 Sep 85 14:17:05-EDT
Date: Wed, 11 Sep 1985 11:05 EDT
Message-ID: <FAHLMAN.12142412824.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Tim McNerney <TIM@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Top-level forms and eval-when in the compiler [and macrolet too!]
In-reply-to: Msg of 11 Sep 1985 01:15-EDT from Tim McNerney <TIM at MIT-MC.ARPA>
Common Lisp compilers are not required to do any work at all, or even to
exist for a given implementation. So it is legal for a CL compiler to
look at your macrolet and just pass it on through untouched. However,
it would be much more tasteful to compile the included forms, with the
lexically scoped macros in effect.
-- Scott
∂11-Sep-85 1232 REM%IMSSS.#Pup@SU-SCORE.ARPA Compiling anonymous functions embedded in structure
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 11 Sep 85 12:31:55 PDT
Received: from IMSSS by Score with Pup; Wed 11 Sep 85 12:30:51-PDT
Date: 11 Sep 1985 1232-PDT
From: Rem@IMSSS
Subject: Compiling anonymous functions embedded in structure
To: COMMON-LISP%SU-AI@SCORE
Instead of saying #'(LAMBDA ...) which the compiler doesn't recognize
as something to compile, you could say (DEFUN TEMPNAME ...) then explicitly
copy that codepointer from the function cell of TEMPNAME to the place it's
really wanted. This is a simple way for the esoteric programmer to get around
this deficiency in the compiler.
By the way, PSL is strange in this respect. When *COMP is turned on so that
forms typed into the interpretor get compiled, it recognizes only PUTD as
a trigger for actual compilation (which in turn is generated by macro expansion
of DE et al), thus it fails to compile the (SETF ... (FUNCTION (LAMBDA ...))).
But when compiling file-to-file using FASLOUT, absolutely everything in
the file is compiled, the toplevel cruft being put in initcode and the stuff
inside (PUTD ...) or (FUNCTION ...) being put in permanent BPS, so that
the original (SETF ...) actually compiles as desired without needing the trick.
-------
∂11-Sep-85 1323 MMcM@SCRC-STONY-BROOK.ARPA LAMBDA expression to the SATISFIES type specifier
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Sep 85 13:23:33 PDT
Received: from MERRIMACK.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 311820; Wed 11-Sep-85 16:20:44-EDT
Date: Wed, 11 Sep 85 16:23 EDT
From: Mike McMahon <MMcM@SCRC-STONY-BROOK.ARPA>
Subject: LAMBDA expression to the SATISFIES type specifier
To: Common-Lisp@SU-AI.ARPA
Message-ID: <850911162347.6.MMCM@MERRIMACK.SCRC.Symbolics.COM>
Page 43 specifies that the predicate name must be a symbol because of
scoping problems.
First off, I don't see any reason to disallow lexical closures:
(deftype foo (x)
`(satisfies ,#'(lambda (y) (eq x y))))
As for LAMBDA expressions, I would think that the same scoping rules
would apply as for DEFMACRO. That is,
(deftype foo (x)
'(satisfies (lambda (y) (eq x y))))
should not be expected to work any more than
(defmacro foo (x y)
`((lambda (z) (eq x z)) ,y))
In summary, I believe that anything FUNCTIONP is valid as the predicate
in SATISFIES. Is there some more subtle scoping problem that I have
overlooked?
∂11-Sep-85 1337 gls@THINK-AQUINAS.ARPA LAMBDA expression to the SATISFIES type specifier
Received: from THINK.COM by SU-AI.ARPA with TCP; 11 Sep 85 13:37:05 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Wed, 11 Sep 85 16:35:29 edt
Date: Wed, 11 Sep 85 16:36 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: LAMBDA expression to the SATISFIES type specifier
To: MMcM@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <850911162347.6.MMCM@MERRIMACK.SCRC.Symbolics.COM>
Message-Id: <850911163632.9.GLS@DESIDERIUS.THINK.COM>
Date: Wed, 11 Sep 85 16:23 EDT
From: Mike McMahon <MMcM@SCRC-STONY-BROOK.ARPA>
Page 43 specifies that the predicate name must be a symbol because of
scoping problems.
First off, I don't see any reason to disallow lexical closures:
(deftype foo (x)
`(satisfies ,#'(lambda (y) (eq x y))))
As for LAMBDA expressions, I would think that the same scoping rules
would apply as for DEFMACRO. That is,
(deftype foo (x)
'(satisfies (lambda (y) (eq x y))))
should not be expected to work any more than
(defmacro foo (x y)
`((lambda (z) (eq x z)) ,y))
In summary, I believe that anything FUNCTIONP is valid as the predicate
in SATISFIES. Is there some more subtle scoping problem that I have
overlooked?
The case I was worried about was
(defun foo (x y)
(declare (type (satisfies (lambda (q) (eq q y))) x))
...)
That's sensible enough, I suppose, but I was leery of the extra
complexity required in a compiler to deal with this (you have to
make closures over type specifiers before handing them off to
SUBTYPEP, etc.).
--Guy
∂11-Sep-85 1446 @SU-SCORE.ARPA,@MIT-REAGAN.ARPA:SOLEY@MIT-MC.ARPA Compiling anonymous functions embedded in structure
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 11 Sep 85 14:46:45 PDT
Received: from MIT-REAGAN.ARPA by SU-SCORE.ARPA with TCP; Wed 11 Sep 85 14:45:41-PDT
Received: from MIT-CHERRY by MIT-REAGAN via CHAOS with CHAOS-MAIL id 7917; Wed 11-Sep-85 17:45:54-EDT
Date: Wed, 11 Sep 85 17:46 EDT
From: SOLEY@MIT-MC.ARPA
Subject: Compiling anonymous functions embedded in structure
To: Rem@IMSSS, COMMON-LISP%SU-AI@SU-SCORE.ARPA
In-Reply-To: The message of 11 Sep 85 15:32-EDT from Rem at IMSSS
Message-ID: <"850911174600.5.Soley@MC"@CHERRY.MIT>
Date: 11 Sep 1985 1232-PDT
From: Rem@IMSSS
Subject: Compiling anonymous functions embedded in structure
To: COMMON-LISP%SU-AI@SCORE
Instead of saying #'(LAMBDA ...) which the compiler doesn't recognize
as something to compile, you could say (DEFUN TEMPNAME ...) then explicitly
copy that codepointer from the function cell of TEMPNAME to the place it's
really wanted. This is a simple way for the esoteric programmer to get around
this deficiency in the compiler.
Yeah, and while we're being esoteric, let's scrap FUNCALL (which should
be called CALL anyway . . .) in favor of the phrase
...
(setf (get '*MAJIC* 'EXPR) <function>)
(*MAJIC* <arg> <arg> <arg>)
...
which I think I actually saw in some piece of MacLisp some time ago . . .
∂11-Sep-85 1935 FAHLMAN@C.CS.CMU.EDU Top-level forms and eval-when in the compiler [and macrolet
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 Sep 85 19:35:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 11 Sep 85 22:36:32-EDT
Date: Wed, 11 Sep 1985 22:36 EDT
Message-ID: <FAHLMAN.12142538569.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Top-level forms and eval-when in the compiler [and macrolet
In-reply-to: Msg of 11 Sep 1985 20:55-EDT from Masinter.pa at Xerox.ARPA
Date: Wednesday, 11 September 1985 20:55-EDT
From: Masinter.pa at Xerox.ARPA
To: Fahlman
Re: Top-level forms and eval-when in the compiler [and macrolet
too!]
Your answer isn't acceptable. No Common Lisp is "serious" unless it has
a compiler, and there are many things in Guy's book that are meaningless
unless there's a compiler (compile-file, declarations, defconst,
optimize, etc.)
While it might have been politic at the time the book was being put
together to say "Common Lisp compilers are not required to do any work
at all, or even to exist for a given implementation", all of the real
ones *do*, and if most implementations have a feature, then the feature
should be standardized.
In answering these queries, I try to keep three things separate: what is
required by the current language definition, as I understand it; what I
think that every reasonable implementation ought to do; and what I think
ought to be added to the language specification in the future. So what
I was saying is that, according to the current definition of Common
Lisp, I think that it is legal either to compile or not to compile a
Defun within a Macrolet; I also said that I thought an implementation
ought to compile such forms. Do you disagree with either of those
statements?
Presumably what you found unacceptable was that the language
specification allowed something like this (and almost everything else
about what the compiler does) to be unspecified. I can't subscribe to
your sweeping statement that "if most implementaitons have a feature,
then the feature should be standardized". Our strategy has been to
standardize all those things which must be standardized in order to
allow code to be portable. Things which do not impact the portability
of code have in general been left unspecified. In particular, we have
tried not to specify too much about the internals of an implementation
so that Common Lisp can be implemented on a wide variety of machines
using a wide variety of implementation techniques. Similarly, we have
not specified more than is absolutely necessary about the user
interface, so that implementors have some freedom in adapting Common
Lisp to thier own system's local culture. We had in mind, for example,
Interlisp people who might want to stick with an internal editor instead
of being required to live with an EMACS front end.
It is of course a tricky balancing act to decide just how much to nail
down. For example, I think that we would all agree that the language
spec ought not to specify exactly which things are to be open-coded by
the compiler and which left as function calls; to do so would be to put
some class of machines at a severe disadvantage. On the other hand,
writers of code intended to be portable will tend to write code whose
performance is optimized according to some assumptions about how most
Common Lisps are organized. For example, they will tend to assume that
it is OK to use macros freely because these are expanded out at compile
time and are probably cached by the interpreter.
If we can make such implementation techniques more uniform without
really screwing any reasonable implementation, then we should probably
do so; it will make it possible to port more code to more machines
without extensive retuning. This could be done by REQUIRING certain
implementation techniques to be followed, or it could be done by
"implementation notes" in the manual suggesting that things be done in
certain ways if at all possible. In the past we have favored the
latter, perhaps because there was so little implementation experience to
draw upon that we didn't want to absolutely rule out any alternatives.
I suppose it would be reasonable to require that Defuns embedded in
random top-level forms get compiled just like top-level Defuns do
(whatever that may entail in a given implementation). At least, future
editions of the manual should make some strong suggestions along these
lines.
-- Scott
∂11-Sep-85 2039 KSH@MIT-MC.ARPA
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 11 Sep 85 20:36:16 PDT
Date: Wed, 11 Sep 85 23:34:13 EDT
From: Kjeld Hvatum <KSH@MIT-MC.ARPA>
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].642224.850911.KSH>
From: Stephen E. Bacher
To: Common LISP mailing list
Re: Modifying constants in compiled code
From Evan Kirshenbaum:
> (defmacro compute-once (form)
> (let ((cell (cons nil nil)))
> `(if (car ',cell) (cdr ',cell)
> (progn
> (setf (car ',cell) t)
> (setf (cdr ',cell) ,form)))))
>
From Bernard S. Greenberg:
> (defun switch ()
> (let ((y '#.(generate-cellx)))
> (prog1 (car y) (rplaca y t))))
>
> (defun generate-cellx () (cons nil nil))
It seems to me that both of the above examples of self-modifying code
that won't modify "read-only" structures are highly dependent upon the
behavior of the compiler. I generally expect the compiler, when it sees
a form (QUOTE (mumble frotz)), to generate machine code to reference a
LISP structure (mumble frotz) built in an area where constants are
habitually placed, most likely a read-only area (if the implementation
permits it).
So what is the difference between '(nil) and '#.(cons nil nil), if we
assume that what the compiler's call to READ returns is what the
compiler sees?
The same applies to a form to be compiled that is the result of a
macro expansion (as in the macro-expansion-time-let example above).
I can see how this might work if you compile from within the LISP
environment and simply create a pointer to previously built LISP
structure, but when you compile a file things are usually different.
At least in my compiler, which works on files only, this is the case.
(And in fact, if the compiler doesn't collapse EQUAL list structures,
which mine doesn't, the first example doesn't work AT ALL anyway!
But that point has already been brought out, so it needs no further
discussion.)
So wherein lies the "non-read-only-ness" of the thing???
∂12-Sep-85 0439 bsg@SCRC-STONY-BROOK.ARPA Not pound-sign dot, fools!
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 Sep 85 04:38:59 PDT
Received: from SCRC-PEGASUS.ARPA by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 312236; Thu 12-Sep-85 07:36:11-EDT
Received: by scrc-pegasus id AA21117; Thu, 12 Sep 85 07:38:53 edt
Date: Thu, 12 Sep 85 07:38:53 edt
From: Bernard S. Greenberg <bsg@scrc-pegasus>
To: ksh@mc
Subject: Not pound-sign dot, fools!
Cc: common-lisp@su-ai
Date: Wed, 11 Sep 85 23:34:13 EDT
From: Kjeld Hvatum <KSH@MIT-MC.ARPA>
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].642224.850911.KSH>
From: Stephen E. Bacher
To: Common LISP mailing list
Re: Modifying constants in compiled code
From Evan Kirshenbaum:
> (defmacro compute-once (form)
> (let ((cell (cons nil nil)))
> `(if (car ',cell) (cdr ',cell)
> (progn
> (setf (car ',cell) t)
> (setf (cdr ',cell) ,form)))))
>
From Bernard S. Greenberg:
> (defun switch ()
> (let ((y '#.(generate-cellx)))
> (prog1 (car y) (rplaca y t))))
>
> (defun generate-cellx () (cons nil nil))
It seems to me that both of the above examples of self-modifying code
that won't modify "read-only" structures are highly dependent upon the
behavior of the compiler. I generally expect the compiler, when it sees
a form (QUOTE (mumble frotz)), to generate machine code to reference a
LISP structure (mumble frotz) built in an area where constants are
habitually placed, most likely a read-only area (if the implementation
permits it).
King of sloppily typing fools, whose typos even work properly.
I meant sharp-sign comma -of course-. Now there's food for thought.
∂12-Sep-85 0536 BSG@SCRC-STONY-BROOK.ARPA Not sharp-sign dot, fools!
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 Sep 85 05:36:17 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 312265; Thu 12-Sep-85 08:33:30-EDT
Date: Thu, 12 Sep 85 08:45 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Not sharp-sign dot, fools!
To: ksh@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 12 Sep 85 07:38-EDT from Mail Delivery Subsystem <MAILER-DAEMON@SCRC-PEGASUS.ARPA>
Message-ID: <850912084526.2.BSG@CONCORD.SCRC.Symbolics.COM>
Date: Wed, 11 Sep 85 23:34:13 EDT
From: Kjeld Hvatum <KSH@MIT-MC.ARPA>
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].642224.850911.KSH>
From: Stephen E. Bacher
To: Common LISP mailing list
Re: Modifying constants in compiled code
From Evan Kirshenbaum:
> (defmacro compute-once (form)
> (let ((cell (cons nil nil)))
> `(if (car ',cell) (cdr ',cell)
> (progn
> (setf (car ',cell) t)
> (setf (cdr ',cell) ,form)))))
>
From Bernard S. Greenberg:
> (defun switch ()
> (let ((y '#.(generate-cellx)))
> (prog1 (car y) (rplaca y t))))
>
> (defun generate-cellx () (cons nil nil))
It seems to me that both of the above examples of self-modifying code
that won't modify "read-only" structures are highly dependent upon the
behavior of the compiler. I generally expect the compiler, when it sees
a form (QUOTE (mumble frotz)), to generate machine code to reference a
LISP structure (mumble frotz) built in an area where constants are
habitually placed, most likely a read-only area (if the implementation
permits it).
King of sloppily typing fools, whose typos even work properly!
Thank you for paying attention!
I meant sharp-sign comma -of course-, where the compiler's
behavior is not an issue. Now there's food for thought.